| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 369607
|
| |
|
|
|
|
|
|
|
|
|
| |
Remove c++ standard library dependency for now for @phosek. They have a
complicated build system that breaks with the fuzzer target here.
Also added a todo to remedy later.
Differential Revision: https://reviews.llvm.org/D66568
llvm-svn: 369606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch introduces `DynamicCastInfo` similar to `DynamicTypeInfo` which
is stored in `CastSets` which are storing the dynamic cast informations of
objects based on memory regions. It could be used to store and check the
casts and prevent infeasible paths.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D66325
llvm-svn: 369605
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: -
Reviewers: NoQ, Szelethus
Reviewed By: NoQ, Szelethus
Differential Revision: https://reviews.llvm.org/D66267
llvm-svn: 369604
|
| |
|
|
| |
llvm-svn: 369603
|
| |
|
|
|
|
|
| |
Buildbots that use GCC failed to compile because overwritten
namespace with variable name
llvm-svn: 369602
|
| |
|
|
| |
llvm-svn: 369601
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The intention for this is to allow reading and printing symbols out from
llvm-nm. Tapi file, and Tapi universal follow a similiar format to
their respective MachO Object format.
The tests are dependent on llvm-nm processing tbd files which is why its in D66160
Reviewers: ributzka, steven_wu, lhames
Reviewed By: ributzka, lhames
Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66159
llvm-svn: 369600
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instructions.
We had an odd combination of WriteJump applied to some memory
instructions and WriteJumpLd applied to register and immediate
instructions.
Thsi should hopefully assign them all correctly.
llvm-svn: 369599
|
| |
|
|
|
|
| |
readability. NFC
llvm-svn: 369598
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D66544
llvm-svn: 369597
|
| |
|
|
|
|
|
|
|
| |
In D65724, I do a pretty thorough explanation about how I'm solving this
problem, I think that summary nails whats happening here ;)
Differential Revision: https://reviews.llvm.org/D65725
llvm-svn: 369596
|
| |
|
|
| |
llvm-svn: 369595
|
| |
|
|
| |
llvm-svn: 369594
|
| |
|
|
| |
llvm-svn: 369593
|
| |
|
|
|
|
|
| |
Locally the tight iterations bounds work fine but the bots seem unhappy.
Try to get green bots and some time to determine the underlying problem.
llvm-svn: 369592
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DependentNameType)
Summary:
This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator
on the template is a DependentNameType - we can only put the gsl::Pointer attribute
on the underlaying record after instantiation)
inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared,
we added the gsl::Pointer on the canonical decl (the forward decl), and later when the
template was instantiated, there was no attribute on the definition so it was not instantiated).
and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to
a incomplete instantiation, and then another was copied from the template definition
when the instantiation was completed).
We now add the attributes to all redeclarations to fix thos issues and make their usage easier.
Reviewers: gribozavr
Subscribers: Szelethus, xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66179
llvm-svn: 369591
|
| |
|
|
| |
llvm-svn: 369590
|
| |
|
|
|
|
|
|
|
|
|
| |
is an interesting field
Exactly what it says on the tin! Note that we're talking about interestingness
in general, hence this isn't a control-dependency-tracking specific patch.
Differential Revision: https://reviews.llvm.org/D65724
llvm-svn: 369589
|
| |
|
|
|
|
|
| |
Function can have users that are not instructions, e.g., bitcasts. For
now, we simply give up when we see them.
llvm-svn: 369588
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AddressRanges
The full GSYM patch started with: https://reviews.llvm.org/D53379
This patch add the ability to encode data using the new llvm::gsym::FileWriter class.
FileWriter is a simplified binary data writer class that doesn't require targets, target definitions, architectures, or require any other optional compile time libraries to be enabled via the build process. This class needs the ability to seek to different spots in the binary data that it produces to fix up offsets and sizes in GSYM data. It currently uses std::ostream over llvm::raw_ostream because llvm::raw_ostream doesn't support seeking which is required when encoding and decoding GSYM data.
AddressRange objects are encoded and decoded to be relative to a base address. This will be the FunctionInfo's start address if the AddressRange is directly contained in a FunctionInfo, or a base address of the containing parent AddressRange or AddressRanges. This allows address ranges to be efficiently encoded using ULEB128 encodings as we encode the offset and size of each range instead of full addresses. This also makes encoded addresses easy to relocate as we just need to relocate one base address.
Differential Revision: https://reviews.llvm.org/D63828
llvm-svn: 369587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To be able to track how many iterations we need to manifest all
information we check for we now make the maximum iteration count
explicit. The count is set tightly now and should be kept that way.
Reviewers: uenoku, sstefan1
Subscribers: bollu, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66554
llvm-svn: 369586
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
should never be taken
I noticed that SourceManager::translateFile has code that doesn't really make sense.
In particular, if it fails to find a FileID by comparing FileEntry * values, it tries to
look through files that have the same filename, to see if they have a matching inode to try to
find the right FileID. However, the inode comparison seem redundant, as Clang's FileManager
already deduplicates FileEntry * values by inode.
Thus the comparisons between inodes should never actually succeed, and the comparison between FileEntry * values should be sufficient here.
Differential Revision: https://reviews.llvm.org/D65481
llvm-svn: 369585
|
| |
|
|
|
|
| |
setting in the cflags on Darwin systems.
llvm-svn: 369584
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We defined (on the mailing list and here on phabricator) 2 different cases where
retrieving information about a control dependency condition is very important:
* When the condition's last write happened in a different stack frame
* When the collapse point of the condition (when we can constrain it to be
true/false) didn't happen in the actual condition.
It seems like we solved this problem with the help of expression value tracking,
and have started working on better diagnostics notes about this process.
Expression value tracking is nothing more than registering a variety of visitors
to construct reports about it. Each of the registered visitors (ReturnVisitor,
FindLastStoreVisitor, NoStoreFuncVisitor, etc) have something to go by: a
MemRegion, an SVal, an ExplodedNode, etc. For this reason, better explaining a
last write is super simple, we can always just pass on some more information to
the visitor in question (as seen in D65575).
ConditionBRVisitor is a different beast, as it was built for a different
purpose. It is responsible for constructing events at, well, conditions, and is
registered only once, and isn't a part of the "expression value tracking
family". Unfortunately, it is also the visitor to tinker with for constructing
better diagnostics about the collapse point problem.
This creates a need for alternative way to communicate with ConditionBRVisitor
that a specific condition is being tracked for for the reason of being a control
dependency. Since at almost all PathDiagnosticEventPiece construction the
visitor checks interestingness, it makes sense to pair interestingness with a
reason as to why we marked an entity as such.
Differential Revision: https://reviews.llvm.org/D65723
llvm-svn: 369583
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the char8_t type introduced in C++20
char8_t. The original patch was submitted by James Blachly on the LLDB
mailing list [1]. I modified the patch a bit and added a test.
[1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html
Differential revision: https://reviews.llvm.org/D66447
llvm-svn: 369582
|
| |
|
|
|
|
|
| |
These call find with a StringRef, heterogenous lookup saves a temporary
std::string there.
llvm-svn: 369581
|
| |
|
|
| |
llvm-svn: 369580
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Tapi files are YAML files that start with the !tapi tag. The only execption are
TBD v1 files, which don't have a tag. In that case we have to scan a little
further and check if the first key "archs" exists.
This is the first patch in a series of patches to add libObject support for
text-based dynamic library (.tbd) files.
This patch is practically exactly the same as D37820, that was never pushed to master,
and is needed for future commits related to reading tbd files for llvm-nm
Reviewers: ributzka, steven_wu, bollu, espindola, jfb, shafik, jdoerfert
Reviewed By: steven_wu
Subscribers: dexonsmith, llvm-commits
Tags: #llvm, #clang, #sanitizers, #lldb, #libc, #openmp
Differential Revision: https://reviews.llvm.org/D66149
llvm-svn: 369579
|
| |
|
|
| |
llvm-svn: 369578
|
| |
|
|
| |
llvm-svn: 369577
|
| |
|
|
| |
llvm-svn: 369576
|
| |
|
|
|
|
|
| |
So far we split the unreachable off and placed a new one, this is not
necessary.
llvm-svn: 369575
|
| |
|
|
|
|
|
|
|
|
| |
Can't add much more to the title! This is part 1, the case where the collapse
point isn't in the condition point is the responsibility of ConditionBRVisitor,
which I'm addressing in part 2.
Differential Revision: https://reviews.llvm.org/D65575
llvm-svn: 369574
|
| |
|
|
| |
llvm-svn: 369573
|
| |
|
|
| |
llvm-svn: 369572
|
| |
|
|
| |
llvm-svn: 369571
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unavailable pred.
Currently we do not properly translate addresses with PHIs if LoadBB !=
LI->getParent(), because PHITranslateAddr expects a direct predecessor as argument,
because it considers all instructions outside of the current block to
not requiring translation.
The amount of cases that trigger this should be very low, as most single
predecessor blocks should be folded into their predecessor by GVN before
we actually start with value numbering. It is still not guaranteed to
happen, so we should do PHI translation along all edges between the
loads' block and the predecessor where we have to place a load.
There are a few test cases showing current limits of the PHI translation, which
could be improved later.
Reviewers: spatel, reames, efriedma, john.brawn
Reviewed By: efriedma
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65020
llvm-svn: 369570
|
| |
|
|
|
|
| |
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/13605/
llvm-svn: 369569
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Finds instances where variables with static storage are initialized dynamically in header files.
Reviewed By: aaron.ballman, alexfh
Patch by Charles Zhang!
Differential Revision: https://reviews.llvm.org/D62829
llvm-svn: 369568
|
| |
|
|
| |
llvm-svn: 369567
|
| |
|
|
|
|
|
|
| |
Fixes: https://github.com/emscripten-core/emscripten/issues/8770
Differential Revision: https://reviews.llvm.org/D66508
llvm-svn: 369566
|
| |
|
|
|
|
|
|
|
| |
I might look at improving PR43065 which will require being
able to mark a 256 and 512 bit vector of f16 as Legal.
Differential Revision: https://reviews.llvm.org/D66515
llvm-svn: 369565
|
| |
|
|
|
|
|
|
| |
This prevents needing to keep the test in sync with ValueTypes.td
This is not the only test that includes ValueTypes.td.
llvm-svn: 369564
|
| |
|
|
|
|
|
|
| |
In case of expanding `lw/sw $reg, symbol($reg)` instruction for PIC it's
enough to call the `loadAndAddSymbolAddress` method. Additional work
performed by the `expandLoadAddress` is not required here.
llvm-svn: 369563
|
| |
|
|
| |
llvm-svn: 369562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These calls change the order in which some nodes are processed and so have an effect on codegen.
The change in fixup-bw-copy.ll is due to (and (load anyext)) gets transformed into (load zext) while previously the and was removed by SimplifyDemandedBits, so the (load anyext) remained.
Reviewers: craig.topper, efriedma, RKSimon, lebedev.ri
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66543
llvm-svn: 369561
|
| |
|
|
|
|
| |
Reverts rL369556 in the process, as it's no longer needed.
llvm-svn: 369560
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds the -lto-obj-path option to lld-link. This can be
used to specify a path at which to write a native object file for
the full LTO part when using LTO unit splitting.
Reviewers: ruiu, tejohnson, pcc, rnk
Reviewed By: ruiu, rnk
Subscribers: mehdi_amini, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65964
llvm-svn: 369559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We cannot create null constants for certain types, e.g. VoidTy,
FunctionTy or LabelTy. getNullValue asserts if we pass in an
unsupported type. We should also check for opaque types, but I'm not
sure how.
This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14795.
Reviewers: t.p.northover, jfb, vsk
Reviewed By: vsk
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65897
llvm-svn: 369557
|