Re-appply r333147, reverted in r333152 due to a pre-existing bug. As
D47308 has been merged in r333206, the OSX issue should now be
resolved.
In many cases JIT users will know in which module a symbol
resides. Avoiding to search other modules can be more efficient. It
also allows to handle duplicate symbol names between modules.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D44889
llvm-svn: 333215
This reverts r333147 until https://reviews.llvm.org/D47308 is ready to
be reviewed. r333147 exposed a behavioural difference between
OrcCBindingsStack::findSymbolIn() and OrcCBindingsStack::findSymbol(),
where only the latter does name mangling. After r333147 that causes a
test failure on OSX, because the new test looks for main using
findSymbolIn() but the mangled name is _main.
llvm-svn: 333152
In many cases JIT users will know in which module a symbol
resides. Avoiding to search other modules can be more efficient. It
also allows to handle duplicate symbol names between modules.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D44889
llvm-svn: 333147
Summary: This patch adds a PDT constructor from Function and lets codes previously using a local class to do this use PostDominatorTree class directly.
Reviewers: davide, kuhar, grosser, dberlin
Reviewed By: kuhar
Author: NutshellySima
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46709
llvm-svn: 333102
Summary: This makes the report much more readable.
Reviewers: gchatelet
Subscribers: tschuett, mgrang, craig.topper, RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D47189
llvm-svn: 332979
The lookup function provides blocking symbol resolution for JIT clients (not
layers themselves) so it does not need to track symbol dependencies via a
MaterializationResponsibility.
llvm-svn: 332897
Change the "recoverable" error callback to take an Error instaed of a
string.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D46831
llvm-svn: 332845
Summary:
In https://reviews.llvm.org/rL332804 I loosed the assertion in
the Clang driver test that forced me to revert
https://reviews.llvm.org/rL332299. Once this lands I should be
able to narrow down what caused PS4 buildbots to fail, and
reinstate the check in that test.
Test Plan: check-llvm & check-clang
llvm-svn: 332805
Aaron Ballman reported that TestPlugin warned about it using exception handling
without /EHsc flag, and that llvmGetPassInfo() had conflicting export
attributes (dllimport in the header, dllexport in the source file).
/EHsc is because TestPlugin didn't use the llvm_ cmake functions, so
llvm_update_compile_flags didn't get called for the target
(llvm_update_compile_flags explicitly passes /Ehs-c-, which fixes the warning).
Use add_llvm_loadable_module instead of add_library(... MODULE) to fix this.
This also has the side effect of not building the plugin on Windows. That's not
a big problem, since before the plugin was built on Windows, but the test
didn't attempt to load it, due to -DLLVM_ENABLE_PLUGIN not being passed to
PluginsTests.cpp during compilation on Windows. This makes the plugin behavior
consistent with e.g. lib/Transforms/Hello/CMakeLists.txt. (This also
automatically sets LTDL_SHLIB_EXT correctly.)
The dllimport/dllexport warning is more serious: Since LLVM doesn't generally
use export annotations for its code, the only way the plugin could link was by
linking in some LLVM libraries both into the test and the dll, so the plugin
would call the llvm code in the dll instead of the copy in the main executable.
This means globals weren't shared, and things generally can't work. (I think
there's a build config where you can build a LLVM.dll which might work, but
that wasn't how the test was configured. If that config is used, the dll should
still be built, but I haven't checked).
Now that add_llvm_loadable_module is used, LLVM_LINK_COMPONENTS got linked into
both executable and plugin on posix too, so unset it after the executable so
that the plugin doesn't end up with a 2nd copy of things on posix.
https://reviews.llvm.org/D47082
llvm-svn: 332796
Provide some free functions to reduce verbosity of endian-writing
a single value, and replace the endianness template parameter with
a field.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47032
llvm-svn: 332757
The idea is that a client that wants split dwarf would create a
specific kind of object writer that creates two files, and use it to
create the streamer.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47050
llvm-svn: 332749
llvm::BitVector::const_set_bits_iterator is not formally a
ForwardIterator. Using it as such results in compile time errors on some
compilers:
FAILED: unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/RegisterAliasingTest.cpp.obj
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xutility(967): error C2794: 'iterator_category': is not a member of any direct or indirect base class of 'std::iterator_traits<_InIt>'
with
[
_InIt=llvm::BitVector::const_set_bits_iterator
]
llvm-svn: 332697
notifyFailed method rather than passing in an error generator.
VSO::notifyFailed is responsible for notifying queries that they will not
succeed due to error. In practice the queries don't care about the details
of the failure, just the fact that a failure occurred for some symbols.
Having VSO::notifyFailed take care of this simplifies the interface.
llvm-svn: 332666
Restructuring the code to measure latency and uops.
The end goal is to have this program spawn another process to deal with SIGILL and other malformed programs. It is not yet the case in this redesign, it is still the main program that runs the code (and may crash).
It now uses BitVector instead of Graph for performance reasons.
https://reviews.llvm.org/D46821
(with fixed ARM tests)
Authored by Guillaume Chatelet
llvm-svn: 332592
Restructuring the code to measure latency and uops.
The end goal is to have this program spawn another process to deal with SIGILL and other malformed programs. It is not yet the case in this redesign, it is still the main program that runs the code (and may crash).
It now uses BitVector instead of Graph for performance reasons.
https://reviews.llvm.org/D46821
Authored by Guillaume Chatelet
llvm-svn: 332579
r332057 introduced distance() for ranges. Based on post-commit feedback,
this renames distance() to size(). The new size() is also only enabled
when the operation is O(1).
Differential Revision: https://reviews.llvm.org/D46976
llvm-svn: 332551
VSOs now track dependencies for materializing symbols. Each symbol must have its
dependencies registered with the VSO prior to finalization. Usually this will
involve registering the dependencies returned in
AsynchronousSymbolQuery::ResolutionResults for queries made while linking the
symbols being materialized.
Queries against symbols are notified that a symbol is ready once it and all of
its transitive dependencies are finalized, allowing compilation work to be
broken up and moved between threads without queries returning until their
symbols fully safe to access / execute.
Related utilities (VSO, MaterializationUnit, MaterializationResponsibility) are
updated to support dependence tracking and more explicitly track responsibility
for symbols from the point of definition until they are finalized.
llvm-svn: 332541
As far as I can tell from revision history, there's no good reason to call
these files .so instead of .dll in Windows, so use the normal extension.
Also change PipSquak from SHARED to MODULE -- it's never passed to
target_link_libraries() and only loaded via dlopen(), so MODULE is more
appropriate. This makes it possible to delete a workaround for SHARED ldflags
being not quite right as well.
No intended behavior change.
https://reviews.llvm.org/D46898
llvm-svn: 332487
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed,
Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja
Reviewed By: rja
Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits
Differential Revision: https://reviews.llvm.org/D45736
llvm-svn: 332452
LLVM uses cpp as its C++ file extension, these are the only three cxx file in
the monorepo. These files apparently were called to escape a CMake check -- use
the LLVM_OPTIONAL_SOURCES mechanism that's meant as an escape for this case
instead.
No intended behavior change.
https://reviews.llvm.org/D46843
llvm-svn: 332368
The asan failures were caught in google internal asan tests after r332311
o Make StackOption support cl::list
o Rememeber to removeArguments for cl::alias in tests.
llvm-svn: 332354
Summary:
AsmTemplate becomes IntructionBenchmarkKey, which has three components.
This allows retreiving the opcode for analysis.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D46873
llvm-svn: 332348
Summary: Arm does not have a ret code per se.
Reviewers: gchatelet
Subscribers: mgorny, javed.absar, kristof.beyls, tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D45672
llvm-svn: 332331
Summary:
bugpoint has several options specified as `PositionalEatArgs` to pass
options through to the underlying tool, e.g. `-tool-args`. The `-help`
message suggests the usage is: `-tool-args=<string>`. However, this is
misleading, because that's not how these arguments work. Rather than taking
a value, the option consumes all positional arguments until the next
recognized option (or all arguments if `--` is specified at some point).
To make this slightly clearer, instead print the help as:
```
-tool-args <string>... - <tool arguments>...
```
Additionally, add an error if the user attempts to use a `PositionalEatArgs`
argument with a value, instead of silently ignoring it. Example:
```
./bin/bugpoint -tool-args=-mpcu=skylake-avx512
bugpoint: for the -tool-args option: This argument does not take a value.
Instead, it consumes any positional arguments until the next recognized option.
```
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D46787
llvm-svn: 332311
Summary:
In https://bugs.llvm.org/show_bug.cgi?id=37006 Nico Weber points out a
flaw in `OptTable::findNearest`: if an option "foo"'s prefixes are "--"
and "-", then the nearest option for "--fob" will be "-foo". This is
incorrect, however, since the function is expected to return "--foo".
The bug is due to a naive loop that attempts to predetermines which
prefix is best. Instead, compute the edit distance for each prefix/name
pair.
Test Plan: `check-llvm`
Reviewers: thakis
Reviewed By: thakis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46776
llvm-svn: 332299
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
- Manual change to APInt
- Manually chage DOCS as regex doesn't match it.
In the transition period the DEBUG() macro is still present and aliased
to the LLVM_DEBUG() one.
Differential Revision: https://reviews.llvm.org/D43624
llvm-svn: 332240
comparison of integers of different signs: 'const unsigned long' and 'const int' [-Werror,-Wsign-compare]
unittests/tools/llvm-exegesis/BenchmarkResultTest.cpp:60:5: note: in instantiation of function template specialization 'testing::internal::EqHelper<false>::Compare<unsigned long, int>' requested here
ASSERT_EQ(FromDiskVector.size(), 1);
llvm-svn: 332235
comparison of integers of different signs: 'const unsigned long' and 'const int' [-Werror,-Wsign-compare]
unittests/tools/llvm-exegesis/BenchmarkResultTest.cpp:60:5: note: in instantiation of function template specialization 'testing::internal::EqHelper<false>::Compare<unsigned long, int>' requested here
ASSERT_EQ(FromDiskVector.size(), 1);
llvm-svn: 332230
Summary:
Currently the order of blocks returned by `IDF::calculate` can be
non-deterministic. This was discovered in several attempts to enable
SSAUpdaterBulk for JumpThreading (which led to miscompare in bootstrap between
stage 3 and stage4). Originally, the blocks were put into a priority queue with
a depth level as their key, and this patch adds a DFSIn number as a second key
to specify a deterministic order across blocks from one level.
The solution was suggested by Daniel Berlin.
Reviewers: dberlin, davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46646
llvm-svn: 332167
Summary: Fix two typos which result in verifying wrong data structures (DT) instead of PDT in DominatorTreeBatchUpdatesTest.
Reviewers: davide, kuhar, grosser, dberlin
Reviewed By: davide, kuhar, dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46696
llvm-svn: 332086
