A year or so ago, I re-wrote most of the lit infrastructure in LLVM so
that it wasn't so boilerplate-y. I added lots of common helper type
stuff, simplifed usage patterns, and made the code more elegant and
maintainable.
We migrated to this in LLVM, clang, and lld's lit files, but not in
LLDBs. This started to bite me recently, as the 4 most recent times I
tried to run the lit test suite in LLDB on a fresh checkout the first
thing that would happen is that python would just start crashing with
unhelpful backtraces and I would have to spend time investigating.
You can reproduce this today by doing a fresh cmake generation, doing
ninja lldb and then python bin/llvm-lit.py -sv ~/lldb/lit/SymbolFile at
which point you'll get a segfault that tells you nothing about what your
problem is.
I started trying to fix the issues with bandaids, but it became clear
that the proper solution was to just bring in the work I did in the rest
of the projects. The side benefit of this is that the lit configuration
files become much cleaner and more understandable as a result.
Differential Revision: https://reviews.llvm.org/D54009
llvm-svn: 346008
Summary:
As a bonus, this arguably improves the code by making it simpler.
gcc 8 on Ubuntu 18.10 reports the following:
==39667==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffffff8ae0 at pc 0x555555dbfc68 bp 0x7fffffff8760 sp 0x7fffffff8750
WRITE of size 8 at 0x7fffffff8ae0 thread T0
#0 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Alloc_hider::_Alloc_hider(char*, std::allocator<char>&&) /usr/include/c++/8/bits/basic_string.h:149
#1 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:542
#2 0x555555dbfc67 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&) /usr/include/c++/8/bits/basic_string.h:6009
#3 0x555555dbfc67 in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:168
(...)
Address 0x7fffffff8ae0 is located in stack of thread T0 at offset 864 in frame
#0 0x555555dbef3f in searchableFieldType /home/nha/amd/build/san/llvm-src/utils/TableGen/SearchableTableEmitter.cpp:148
Reviewers: fhahn, simon_tatham, kparzysz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53931
llvm-svn: 345749
Before this patch, class PredicateExpander only knew how to expand simple
predicates that performed checks on instruction operands.
In particular, the new scheduling predicate syntax was not rich enough to
express checks like this one:
Foo(MI->getOperand(0).getImm()) == ExpectedVal;
Here, the immediate operand value at index zero is passed in input to function
Foo, and ExpectedVal is compared against the value returned by function Foo.
While this predicate pattern doesn't show up in any X86 model, it shows up in
other upstream targets. So, being able to support those predicates is
fundamental if we want to be able to modernize all the scheduling models
upstream.
With this patch, we allow users to specify if a register/immediate operand value
needs to be passed in input to a function as part of the predicate check. Now,
register/immediate operand checks all derive from base class CheckOperandBase.
This patch also changes where TIIPredicate definitions are expanded by the
instructon info emitter. Before, definitions were expanded in class
XXXGenInstrInfo (where XXX is a target name).
With the introduction of this new syntax, we may want to have TIIPredicates
expanded directly in XXXInstrInfo. That is because functions used by the new
operand predicates may only exist in the derived class (i.e. XXXInstrInfo).
This patch is a non functional change for the existing scheduling models.
In future, we will be able to use this richer syntax to better describe complex
scheduling predicates, and expose them to llvm-mca.
Differential Revision: https://reviews.llvm.org/D53880
llvm-svn: 345714
The intent here was to run check-llvm/check-clang in the instrumented
clang's build directory, not the maybe-not-yet-created uninstrumented
clang's. Oops. :)
llvm-svn: 345461
Depending on who you ask, PGO grants a 15%-25% improvement in build
times when using clang. Sadly, hooking everything up properly to
generate a profile and apply it to clang isn't always straightforward.
This script (and the accompanying docs) aim to make this process easier;
ideally, a single invocation of the given script.
In terms of testing, I've got a cronjob on my Debian box that's meant to
run this a few times per week, and I tried manually running it on a puny
Gentoo box I have (four whole Atom cores!). Nothing obviously broke.
¯\_(ツ)_/¯
I don't know if we have a Python style guide, so I just shoved this
through yapf with all the defaults on.
Finally, though the focus is clang at the moment, the hope is that this
is easily applicable to other LLVM-y tools with minimal effort (e.g.
lld, opt, ...). Hence, this lives in llvm/utils and tries to be somewhat
ambiguous about naming.
Differential Revision: https://reviews.llvm.org/D53598
llvm-svn: 345427
Currently, the regular expression that matches the lines of assembly for PPC LE
(ELFv2) does not work for the assembly for BE (ELFv1). This patch fixes it.
Differential revision: https://reviews.llvm.org/D53059
llvm-svn: 345363
Summary:
The pfm counters are now in the ExegesisTarget rather than the
MCSchedModel (PR39165).
This also compresses the pfm counter tables (PR37068).
Reviewers: RKSimon, gchatelet
Subscribers: mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D52932
llvm-svn: 345243
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
Summary:
Some targets have very long encodings and uint64_t isn't sufficient. uint128_t
isn't portable so such targets need to use an object instead.
There is one catch with this at the moment, no string of bits extracted
from the encoding may exceeed 64-bits. Fields are still permitted to
exceed 64-bits so long as they aren't one contiguous string of bits. If
this proves to be a problem then we can modify the generation of
fieldFromInstruction() calls to account for it but for now I've added an
assertion for this.
InsnType must either be integral or an APInt-like object that must:
* Have a static const max_size_in_bits equal to the number of bits in the encoding.
* be default-constructible and copy-constructible
* be constructible from a uint64_t (this is the key area the interface deviates
from APInt since this constructor does not take the bit width)
* be constructible from an APInt (this can be private)
* be convertible to uint64_t
* Support the ~, &,, ==, !=, and |= operators with other objects of the same type
* Support shift (<<, >>) with signed and unsigned integers on the RHS
* Support put (<<) to raw_ostream&
Reviewers: bogner, charukcs
Subscribers: nhaehnle, llvm-commits
Differential Revision: https://reviews.llvm.org/D52100
llvm-svn: 345056
Some versions of bash.exe, for example WSL's version expect paths in the form
/mnt/c/path/to/dir rather than c:\\path\\to\\dir so will cause failures
for any tests that require an external shell if used by lit. If we're on
Windows and looking for an external shell, check that the found version
of bash is able to parse a native path before returning that version.
This patch also partially reverts the behaviour of r228221 by
restoring the warning if bash cannot be found. This shouldn't pollute
the lit stderr anymore as we're now using internal shell by default on
Windows. If someone is explicitly specifying to use an external shell, it's
probably worth alerting them to the fact that bash could not be found.
Differential Revision: https://reviews.llvm.org/D52831
llvm-svn: 345019
Summary:
Replace its functionality with a TableGen InstrInfo relational
instruction mapping. Although arguably more complex than the TableGen
backend, the relational mapping is a smaller maintenance burden than a
TableGen backend.
Reviewers: aardappel, aheejin, dschuff
Subscribers: mgorny, sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D53307
llvm-svn: 344962
The vectoriser's debug log prints VPlan digraphs, but it's a bit
cumbersome to extract them and render them into PNG images. This script
does exactly that, being careful enough to extract all individual plans,
name them appropriately and save in either .dot or .png files.
Example usage:
$ opt -O3 -debug-only=loop-vectorize file.ll -S -o /dev/null 2> debug.log
$ $LLVM_SRC/utils/extract_vplan.py < debug.log
Exporting VF1UF1 to DOT: VPlanVF1UF1.dot
Exporting VF24UF1 to DOT: VPlanVF24UF1.dot
$ $LLVM_SRC/utils/extract_vplan.py --png < debug.log
Exporting VF1UF1 to PNG via dot: VPlanVF1UF1.png
Exporting VF24UF1 to PNG via dot: VPlanVF24UF1.png
$ xdot VPlanVF1UF1.dot
Differential Revision: https://reviews.llvm.org/D53142
llvm-svn: 344599
This patch adds the ability to identify instructions that are "move elimination
candidates". It also allows scheduling models to describe processor register
files that allow move elimination.
A move elimination candidate is an instruction that can be eliminated at
register renaming stage.
Each subtarget can specify which instructions are move elimination candidates
with the help of tablegen class "IsOptimizableRegisterMove" (see
llvm/Target/TargetInstrPredicate.td).
For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated.
The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this:
```
def : IsOptimizableRegisterMove<[
InstructionEquivalenceClass<[
// GPR variants.
MOV32rr, MOV64rr,
// MMX variants.
MMX_MOVQ64rr,
// SSE variants.
MOVAPSrr, MOVUPSrr,
MOVAPDrr, MOVUPDrr,
MOVDQArr, MOVDQUrr,
// AVX variants.
VMOVAPSrr, VMOVUPSrr,
VMOVAPDrr, VMOVUPDrr,
VMOVDQArr, VMOVDQUrr
], CheckNot<CheckSameRegOperand<0, 1>> >
]>;
```
Definitions of IsOptimizableRegisterMove from processor models of a same
Target are processed by the SubtargetEmitter to auto-generate a target-specific
override for each of the following predicate methods:
```
bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI)
const;
bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned
CPUID) const;
```
By default, those methods return false (i.e. conservatively assume that there
are no move elimination candidates).
Tablegen class RegisterFile has been extended with the following information:
- The set of register classes that allow move elimination.
- Maxium number of moves that can be eliminated every cycle.
- Whether move elimination is restricted to moves from registers that are
known to be zero.
This patch is structured in three part:
A first part (which is mostly boilerplate) adds the new
'isOptimizableRegisterMove' target hooks, and extends existing register file
descriptors in MC by introducing new fields to describe properties related to
move elimination.
A second part, uses the new tablegen constructs to describe move elimination in
the BtVer2 scheduling model.
A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove'
hook to mark instructions that are candidates for move elimination. It also
teaches class RegisterFile how to describe constraints on move elimination at
PRF granularity.
llvm-mca tests for btver2 show differences before/after this patch.
Differential Revision: https://reviews.llvm.org/D53134
llvm-svn: 344334
Summary:
The script to generate code coverage reports supports passing filter paths to llvm-cov when generating the HTML reports, but doesn't pass those paths to the summary generation as well. This results in a summary report that doesn't match the HTML report.
This patch addresses the problem by also passing the filter paths to the summary report generation.
Reviewers: vsk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53110
llvm-svn: 344217
This patch fixes three issues.
The first is that we didn't consider files which are explicitly
set to eolstyle CRLF in the repo, and there are a handful of
these.
Second is that dos2unix doesn't have a -q option in GnuWin32,
so this codepath wasn't working properly.
Finally with newer versions of Python (or newer versions of Git,
or some combination of the two) patches can't be applied when
we treat stdin as text, because Python silently undoes all the
work we did to convert the newlines to LF using dos2unix by
using universal_newlines=True and then converting them *back*
to CRLF. So we need to add a way to force stdin to be treated
as binary, and use it when LF-newlines are required.
Differential Revision: https://reviews.llvm.org/D51444
llvm-svn: 344095
Summary:
The predicate function is added in InlinePatternFragments, no need to
do it here. As a result, all uses of addPredicateFn are located in
InlinePatternFragments.
Test confirmed that there are no changes to generated files when
building all (non-experimental) targets.
Change-Id: I720e42e045ca596eb0aa339fb61adf6fe71034d5
Reviewers: arsenm, rampitec, RKSimon, craig.topper, hfinkel, uweigand
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D51993
llvm-svn: 343977
There are a few leftovers in rL343163 which span two lines. This commit
changes these llvm::sort(C.begin(), C.end, ...) to llvm::sort(C, ...)
llvm-svn: 343426
If any prefixes have been specified on the RUN lines that do not end up
ever actually getting printed, raise an Error. This is either an
indication that the run lines just need cleaning up, or that something
is more fundamentally wrong with the test.
Also raise an Error if there are any blocks which cannot be checked
because they are not uniquely covered by a prefix.
Fixed up a couple of tests where the extra checking flagged up issues.
Differential Revision: https://reviews.llvm.org/D48276
llvm-svn: 343332
Insert empty blocks to cause the positions of matching blocks to match
across lists where possible so that later stages of the algorithm can
actually identify them as being identical.
Regenerated all tests with this change.
Differential Revision: https://reviews.llvm.org/D52560
llvm-svn: 343331
Summary: This directory was missing from the lit package on pypi.org.
Reviewers: ddunbar
Subscribers: delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D51670
llvm-svn: 343115
Summary:
By using the existing isCodeGenOnly bit in the tablegen defs, as
suggested by tlively in https://reviews.llvm.org/D51662
Tested: llvm-lit -v `find test -name WebAssembly`
Reviewers: tlively
Subscribers: dschuff, sbc100, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D52373
llvm-svn: 342772
Summary:
This ensures we have the non-register version of the instruction.
The stack version of call_indirect now wants a type index argument,
so that has been added in the existing tests.
Tested:
llvm-lit -v `find test -name WebAssembly`
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51662
llvm-svn: 342753
Summary:
This reverts r329475 which applied to googlemock. This change makes the
googlemock implementation in LLVM dependent on LLVM unnecessarily.
Reviewers: echristo, mgrang
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52287
llvm-svn: 342612
The reason why build #25777 might have failed is because the SmallVector move
constructor is _not_ noexcept, and the stl implementation used by that buildbot
calls _VSTD::move_if_noexcept() (according to the backtrace).
OpcodeInfo has a default move constructor, and the copy constructor is deleted.
However, as far as I can see, SmallVector doesn't declare a noexcept move
constructor. So, what I believe it is happening here is that,
_VSTD::move_if_noexcept() returns an lvalue reference and not an rvalue
reference.
This eventually triggers a copy that fails to compile.
Hopefully, using a std::vector instead of SmallVector (as it was originally
suggested by Simon in the code review) should be enough to unbreak the buildbot.
llvm-svn: 342561
This patch adds the ability for processor models to describe dependency breaking
instructions.
Different processors may specify a different set of dependency-breaking
instructions.
That means, we cannot assume that all processors of the same target would use
the same rules to classify dependency breaking instructions.
The main goal of this patch is to provide the means to describe dependency
breaking instructions directly via tablegen, and have the following
TargetSubtargetInfo hooks redefined in overrides by tabegen'd
XXXGenSubtargetInfo classes (here, XXX is a Target name).
```
virtual bool isZeroIdiom(const MachineInstr *MI, APInt &Mask) const {
return false;
}
virtual bool isDependencyBreaking(const MachineInstr *MI, APInt &Mask) const {
return isZeroIdiom(MI);
}
```
An instruction MI is a dependency-breaking instruction if a call to method
isDependencyBreaking(MI) on the STI (TargetSubtargetInfo object) evaluates to
true. Similarly, an instruction MI is a special case of zero-idiom dependency
breaking instruction if a call to STI.isZeroIdiom(MI) returns true.
The extra APInt is used for those targets that may want to select which machine
operands have their dependency broken (see comments in code).
Note that by default, subtargets don't know about the existence of
dependency-breaking. In the absence of external information, those method calls
would always return false.
A new tablegen class named STIPredicate has been added by this patch to let
processor models classify instructions that have properties in common. The idea
is that, a MCInstrPredicate definition can be used to "generate" an instruction
equivalence class, with the idea that instructions of a same class all have a
property in common.
STIPredicate definitions are essentially a collection of instruction equivalence
classes.
Also, different processor models can specify a different variant of the same
STIPredicate with different rules (i.e. predicates) to classify instructions.
Tablegen backends (in this particular case, the SubtargetEmitter) will be able
to process STIPredicate definitions, and automatically generate functions in
XXXGenSubtargetInfo.
This patch introduces two special kind of STIPredicate classes named
IsZeroIdiomFunction and IsDepBreakingFunction in tablegen. It also adds a
definition for those in the BtVer2 scheduling model only.
This patch supersedes the one committed at r338372 (phabricator review: D49310).
The main advantages are:
- We can describe subtarget predicates via tablegen using STIPredicates.
- We can describe zero-idioms / dep-breaking instructions directly via
tablegen in the scheduling models.
In future, the STIPredicates framework can be used for solving other problems.
Examples of future developments are:
- Teach how to identify optimizable register-register moves
- Teach how to identify slow LEA instructions (each subtarget defining its own
concept of "slow" LEA).
- Teach how to identify instructions that have undocumented false dependencies
on the output registers on some processors only.
It is also (in my opinion) an elegant way to expose knowledge to both external
tools like llvm-mca, and codegen passes.
For example, machine schedulers in LLVM could reuse that information when
internally constructing the data dependency graph for a code region.
This new design feature is also an "opt-in" feature. Processor models don't have
to use the new STIPredicates. It has all been designed to be as unintrusive as
possible.
Differential Revision: https://reviews.llvm.org/D52174
llvm-svn: 342555
This fixes building for Windows on ARM, with MinGW headers.
(Building for Windows on ARM with Windows SDK still is unsupported
by the benchmark library.)
Differential Revision: https://reviews.llvm.org/D52262
llvm-svn: 342549
Further extension to D51035, this patch avoids all repeated predicates[] matching by caching as it collects the patterns that have multiple variants.
Saves around 25secs in debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D51839
llvm-svn: 342467
The windows SDK headers don't have self-consistent casing anyway,
so we consistently use lowercase for these in other places, in order
to fix crosscompilation with mingw headers.
This applies an upstream commit:
5261307982
Differential Revision: https://reviews.llvm.org/D52181
llvm-svn: 342450
Summary:
The multiprocess module uses pickling to transfer
information between processes and does not know how to pickle
the class created in the lit.cfg file and thus the example
fails.
Implement ManyTests in a separate file and import for the
example test passes
Patch by Nathan Lanza <nathan@lanza.io>
Differential Revision: https://reviews.llvm.org/D51328
llvm-svn: 342269
Summary: This is the only test that is still failing on Windows - or rather, it is expected to fail on the bots, but passes on the new bot that we're preparing causing a failure, so I'm going to disable it. Since the test has rarely, if ever, passed on the bots, this should have the same effect and it will unblock the creation of the new bot.
Reviewers: asmith, delcypher, zturner
Subscribers: stella.stamenova, llvm-commits
Differential Revision: https://reviews.llvm.org/D51871
llvm-svn: 341856
`MSVC` is true for clang-cl, but `"${CMAKE_CXX_COMPILER_ID}" STREQUAL
"MSVC"` is false, so we would enable -Wall, which means -Weverything
with clang-cl, and we get tons of undesired warnings.
Use the simpler condition to fix things.
llvm-svn: 341717
- Refactor/rewrite most of the code. Also make sure it passes
pycodestyle/pyflakes now
- Add a new mode that performs bisection on the search space. This
should be faster in the common case where there is only a small number
of files or functions actually leading to failure.
The previous sequential behavior can still be accessed via `--seq`.
llvm-svn: 341679
This patch applies upstream commit:
f0901417c8
Tim Northover pointed out that benchmark build might be broken on 32-bit
macOS. This commit by Roman Lebedev (lebedev.ri) resolves the issue.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D51677
llvm-svn: 341469
Summary:
The python executable may not exist on all systems so use sys.executable
instead.
Reviewers: ddunbar, stella.stamenova
Subscribers: delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D51511
llvm-svn: 341244
Summary:
Now uses the StackBased bit from the tablegen defs to identify
stack instructions (and ignore register based or non-wasm instructions).
Also changed how we store operands, since we now have up to 16 of them
per instruction. To not cause static data bloat, these are compressed
into a tiny table.
+ a few other cleanups.
Tested:
- MCTest
- llvm-lit -v `find test -name WebAssembly`
Reviewers: dschuff, jgravelle-google, sunfish, tlively
Subscribers: sbc100, aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D51320
llvm-svn: 341081
Summary:
Add comments to help readers avoid having to read tablegen backends to
understand the code. Also remove unecessary breaks from the output.
Reviewers: dschuff, aheejin
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51371
llvm-svn: 340864
Summary:
Right now this test is failing on the builtbots on Windows but we have a very similar setup where the test passes. The test is meant to test that specifying a timeout works correctly by running an infnite loop and having it timeout - on the buildbot, the infinite loop doesn't actually execute. This change runs all of the tests in the set using an internal shell rather than an external shell. I expect this will make the test pass which means that either the way the external shell is invoked or the external shell setup on the buildbots is not correct. Regardless of whether the test passes with this change, we'll need to undo this change and have a real fix.
@gkistanova was able to get logs from the buildbot to rule out a number of theories as to why this test is failing, but they didn't have enough information to confirm exactly what the issue is. The purpose of this change is to narrow it down, but if someone has a local repro and can aid in debugging, that would make it much speedier (and less prone to making the bots fail).
Reviewers: gkistanova, asmith, zturner, modocache, rnk, delcypher
Reviewed By: rnk
Subscribers: delcypher, llvm-commits, gkistanova
Differential Revision: https://reviews.llvm.org/D51326
llvm-svn: 340840
CodeGenDAGPatterns::GenerateVariants is a costly function in many tblgen commands (33.87% of the total runtime of x86 -gen-dag-isel), and due to the O(N^2) nature of the function, there are a high number of repeated comparisons of the pattern's vector<Predicate>.
This initial patch at least avoids repeating these comparisons for every Variant in a pattern. I began investigating caching all the matches before entering the loop but hit issues with how best to store the data and how to update the cache as patterns were added.
Saves around 15secs in debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D51035
llvm-svn: 340837
ompiling benchmark library (introduced in D50894) with the latest
bootstrapped Clang produces a lot of warnings, this issue was addressed
in the upstream patch I pushed earlier.
Upstream patch:
f85304e4e3
`README.LLVM` notes were updated to reflect the latest changes.
Reviewed by: lebedev.ri
Differential Revision: https://reviews.llvm.org/D51342
llvm-svn: 340811
This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any
project could use it for benchmark generation. A dummy benchmark is
added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of
the build process.
The current version does not utilize LLVM LNT and LLVM CMake
infrastructure, but that might be sufficient for most users. Two
introduced CMake variables:
* `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark
targets
* `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated
benchmark targets to the list of default LLVM targets (i.e. if `ON`
benchmarks will be built upon standard build invocation, e.g. `ninja` or
`make` with no specific targets)
List of modifications:
* `BENCHMARK_ENABLE_TESTING` is disabled
* `BENCHMARK_ENABLE_EXCEPTIONS` is disabled
* `BENCHMARK_ENABLE_INSTALL` is disabled
* `BENCHMARK_ENABLE_GTEST_TESTS` is disabled
* `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled
Original discussion can be found here:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html
Reviewed by: dberris, lebedev.ri
Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines,
dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D50894
llvm-svn: 340809
Summary:
The new stackification backend generates the giant switch statement
used to translate instructions to their stackified forms. I did this
because it was more interesting than adding all the different vector
versions of the various SIMD instructions to the switch statment
manually.
Reviewers: aardappel, aheejin, dschuff
Subscribers: mgorny, sbc100, jgravelle-google, sunfish, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D51318
llvm-svn: 340781
Summary:
So far, `isReturn` property is used to mean both a return instruction
from a functon and the end of an EH scope, a scope that starts with a EH
scope entry BB and ends with a catchret or a cleanupret instruction.
Because WinEH uses funclets, all EH-scope-ending instructions are also
real return instruction from a function. But for wasm, they only serve
as the end marker of an EH scope but not a return instruction that
exits a function. This mismatch caused incorrect prolog and epilog
generation in wasm EH scopes. This patch fixes this.
This patch is in the same vein with rL333045, which splits
`MachineBasicBlock::isEHFuncletEntry` into `isEHFuncletEntry` and
`isEHScopeEntry`.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D50653
llvm-svn: 340325
We were just caching the MVT set of legal types, then every call creating a new TypeSetByHwMode with it and passing it back on the stack. There's no need to do this - we can create and cache the whole TypeSetByHwMode once and return a const reference to it each time.
Additionally, TypeInfer::expandOverloads wasn't making use of the fact that the cache just contains a default mode containing all the types.
Saves up to 30secs in debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D50903
llvm-svn: 340042
This operator is called a great deal, by checking for the cheap isSimple equality cases first (a common occurrence) we can improve performance as we avoid a lot of std::map find/iteration in hasDefault.
isSimple also means that a default value is present, so we can avoid some hasDefault calls.
This also avoids a rather dodgy piece of logic that was checking for isSimple() && !VTS.isSimple() but not the inverse - it now uses the general hasDefault mode comparison test instead.
Saves around 15secs in debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D50841
llvm-svn: 339890
I noticed this during profiling of tablegen (PR28222) that we were calling Child->getType(0) which creates a ValueTypeByHwMode on the fly from the requested internal TypeSetByHwMode type and returns it by value, we then treat it as a TypeSetByHwMode reference which involves constructing a new TypeSetByHwMode on the stack with a large amount of std::map iterating/copying all along the way.
I am not an expert on tablegen, but AFAICT this is all unnecessary and we should be calling Child->getExtType(0) which returns the original TypeSetByHwMode by reference.
This gives me a 90sec reduction in msvc debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D50789
llvm-svn: 339812
This patch removes redundant template argument `TargetName` from TIIPredicate.
Tablegen can always infer the target name from the context. So we don't need to
force users of TIIPredicate to always specify it.
This allows us to better modularize the tablegen class hierarchy for the
so-called "function predicates". class FunctionPredicateBase has been added; it
is currently used as a building block for TIIPredicates. However, I plan to
reuse that class to model other function predicate classes too (i.e. not just
TIIPredicates). For example, this can be a first step towards implementing
proper support for dependency breaking instructions in tablegen.
This patch also adds a verification step on TIIPredicates in tablegen.
We cannot have multiple TIIPredicates with the same name. Otherwise, this will
cause build errors later on, when tablegen'd .inc files are included by cpp
files and then compiled.
Differential Revision: https://reviews.llvm.org/D50708
llvm-svn: 339706
The behavior in 64-bit mode is different between Intel and AMD CPUs. Intel ignores the 0x66 prefix. AMD does not. objump doesn't ignore the 0x66 prefix. Since LLVM aims to match objdump behavior, we should do the same.
While I was trying to fix this I had change brtarget16/32 to use ENCODING_IW/ID instead of ENCODING_Iv to get the 0x66+REX.W case to act sort of sanely. It's still wrong, but that's a problem for another day.
The change in encoding exposed the fact that 16-bit mode disassembly of relative jumps was creating JMP_4 with a 2 byte immediate. It should have been JMP_2. From just printing you can't tell the difference, but if you dumped the encoding it wouldn't have matched what we started with.
While fixing that, it exposed that jo/jno opcodes were missing from the switch that this patch deleted and there were no test cases for them.
Fixes PR38537.
llvm-svn: 339622
This is a follow-up of r339552.
As pointed out by Craig in D50566, we don't need a formatted_raw_ostream to
indent strings. We can use instead raw_ostream::indent().
Internally, class PredicateExpander already keeps track of the current
indentation level. Also, the grammar for predicates is well parenthesized, and
therefore we don't need to use a formatted_raw_ostream to continuously track the
column number. Instead we can safely replace all the uses of
formatted_raw_ostream::PadToColumn() with uses of raw_ostream::indent().
By replacing formatted_raw_ostream with a simpler raw_ostream, we also avoid the
implicit check on the newline character on every print to stream.
No functional change intended.
llvm-svn: 339577
This patch refactors the logic that expands predicates of a variant scheduling
class.
The idea is to improve the readability of the auto-generated code by removing
redundant parentheses around predicate expressions, and by removing redundant
if(true) statements.
This patch replaces the definition of NoSchedPred in TargetSchedule.td with an
instance of MCSchedPredicate. The new definition is sematically equivalent to
the previous one. The main difference is that now SubtargetEmitter knows that it
represents predicate "true".
Before this patch, we always generated an if (true) for the default transition
of a variant scheduling class.
Example (taken from AArch64GenSubtargetInfo.inc) :
```
if (SchedModel->getProcessorID() == 3) { // CycloneModel
if ((TII->isScaledAddr(*MI)))
return 927; // (WriteIS_WriteLD)_ReadBaseRS
if ((true))
return 928; // WriteLD_ReadDefault
}
```
Extra parentheses were also generated around the predicate expressions.
With this patch, we get the following auto-generated checks:
```
if (SchedModel->getProcessorID() == 3) { // CycloneModel
if (TII->isScaledAddr(*MI))
return 927; // (WriteIS_WriteLD)_ReadBaseRS
return 928; // WriteLD_ReadDefault
}
```
The new auto-generated code behaves exactly the same as before. So, technically
this is a non functional change.
Differential revision: https://reviews.llvm.org/D50566
llvm-svn: 339552
Part of the logic has been moved to helper functions to (hopefully) improve
readability.
Added a few code comments to better describe how the algorithm works.
No functional change intended.
llvm-svn: 339421
This patch introduces tablegen class MCStatement.
Currently, an MCStatement can be either a return statement, or a switch
statement.
```
MCStatement:
MCReturnStatement
MCOpcodeSwitchStatement
```
A MCReturnStatement expands to a return statement, and the boolean expression
associated with the return statement is described by a MCInstPredicate.
An MCOpcodeSwitchStatement is a switch statement where the condition is a check
on the machine opcode. It allows the definition of multiple checks, as well as a
default case. More details on the grammar implemented by these two new
constructs can be found in the diff for TargetInstrPredicates.td.
This patch makes it easier to read the body of auto-generated TargetInstrInfo
predicates.
In future, I plan to reuse/extend the MCStatement grammar to describe more
complex target hooks. For now, this is just a first step (mostly a minor
cosmetic change to polish the new predicates framework).
Differential Revision: https://reviews.llvm.org/D50457
llvm-svn: 339352
Summary:
The interface to get size and spill size of a register
was moved from MCRegisterInfo to TargetRegisterInfo over
a year ago. Afaik the old interface has bee around
to give out-of-tree targets a chance to adapt to the
new interface.
One problem with the old MCRegisterClass::PhysRegSize was that
it represented the size of a register as "size in bits" / 8.
So a register had to be a multiple of eight bits wide for the
size to be correct (and the byte size for the target needed to
be eight bits).
Reviewers: kparzysz, qcolombet
Reviewed By: kparzysz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47199
llvm-svn: 339350
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
llvm-svn: 339307
Summary:
This particular map is hardly ever queried and has a phased usage pattern (insert,
iterate, query, insert, iterate) so it's a good candidate for a sorted vector and
std::lower_bound.
This significantly reduces the run time of runTargetDesc() in some circumstances.
One llvm-tblgen invocation in my build improves the time spent in runTargetDesc()
from 9.86s down to 0.80s (~92%) without changing the output. The same invocation
also has 2GB less allocation churn.
Reviewers: bogner, rtereshin, aditya_nandakumar, volkan
Reviewed By: rtereshin
Subscribers: mgrang, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D50272
llvm-svn: 339208
https://reviews.llvm.org/D50283
reviewed by bogner
This patch refactors FileCheck's implementation into support so it can
be used from C++ in other places (Unit tests).
llvm-svn: 339192
This test passes on Windows when using Python 3 but fails when using Python 2, so it needs more investigation before it can be enabled as the bots use Python 2.
llvm-svn: 339184
Summary:
In Python2 'unicode' is a distinct type from 'str', but in Python3 'unicode' does not exist and instead all 'str' objects are Unicode string. This change updates the logic in the test logging for lit to correctly process each of the types, and more importantly, to not just fail in Python3.
This change also reverses the use of quotes in several of the cfg files. By using '""' we are guaranteeing that the resulting path will work correctly on Windows while "''" only works correctly sometimes. This also fixes one of the failing tests.
Reviewers: asmith, zturner
Subscribers: stella.stamenova, delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D50397
llvm-svn: 339179
Summary:
The problem here is that on windows double quotes are used for paths (usually) while single quotes are not. This is not generally a problem for the tests because the lit infrastructure tends to treat both the same. One (and possibly only) exception is when some tests are run in an external shell such as some of the shtest-format tests. In this case on windows the path to python was not created correctly because it had single quotes and the test failed.
This same test is already failing with python 3 which is why our testing missed the new failure. This patch will take care of the immediate failure with python 2 and I'll send a follow up for the python 3 failure.
Reviewers: asmith, zturner
Subscribers: delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D50373
llvm-svn: 339091
Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.
This change updates several configuration files which specify the path to python as a substitution and also remove quotes from existing tests.
Reviewers: asmith, zturner, alexshap, jakehehrlich
Reviewed By: zturner, alexshap, jakehehrlich
Subscribers: mehdi_amini, nemanjai, eraman, kbarton, jakehehrlich, steven_wu, dexonsmith, stella.stamenova, delcypher, llvm-commits
Differential Revision: https://reviews.llvm.org/D50206
llvm-svn: 339073
Zachary Turner