All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).
llvm-svn: 318490
This is still broken because it causes certain tests to be
run twice with slightly different configurations, which is
wrong in some cases.
You can observe this by running:
ninja -nv check-all | grep debuginfo-tests
And seeing that it passes clang/test and clang/test/debuginfo-tests
to lit, which causes it to run debuginfo-tests twice. The fix is
going to involve either:
a) figuring out that we're running in this "deprecated" configuration,
and then deleting the clang/test/debuginfo-tests path, which should
cause it to behave identically to before, or:
b) make lit smart enough that it doesn't descend into a sub-suite if
that sub-suite already has a lit.cfg file.
llvm-svn: 318486
This was reverted due to some failures on specific darwin buildbots,
the issue being that the new lit configuration was not setting the
SDKROOT environment variable. We've tested a fix locally and confirmed
that it works, so this patch resubmits everything with the fix
applied.
llvm-svn: 318435
Summary:
This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV,
causes TableGen to instrument the generated table to collect rule coverage
information. However, LLVM_ENABLE_GISEL_COV goes a bit further than
LLVM_ENABLE_DAGISEL_COV. The information is written to files
(${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be
concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will
read this information and use it to emit warnings about untested rules.
This technique could also be used by SelectionDAG and can be further
extended to detect hot rules and give them priority over colder rules.
Usage:
* Enable LLVM_ENABLE_GISEL_COV in CMake
* Build the compiler and run some tests
* cat gisel-coverage-[0-9]* > gisel-coverage-all
* Delete lib/Target/*/*GenGlobalISel.inc*
* Build the compiler
Known issues:
* ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual
step due to a lack of a portable 'cat' command. It should be the
concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files.
* There's no mechanism to discard coverage information when the ruleset
changes
Depends on D39742
Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka
Reviewed By: rovka
Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D39747
llvm-svn: 318356
This is a tablegen backend to generate documentation for the opcodes that exist
for each target. For each opcode, it lists the assembly string, the names and
types of all operands, and the flags and predicates that apply to the opcode.
Differential revision: https://reviews.llvm.org/D31025
llvm-svn: 318155
This reverts the aforementioned patch and 2 subsequent follow-ups,
as some buildbots are still failing 2 tests because of it.
Investigation is ongoing into the cause of the failures.
llvm-svn: 318112
Similar to r315841, GlobalISel and SelectionDAG require different code for the
common atomic predicates due to differences in the representation.
Even without that, differences in the IR (SDNode vs MachineInstr) require
differences in the C++ predicate.
This patch moves the implementation of the common atomic predicates related to
ordering into tablegen so that it can handle these differences.
It's NFC for SelectionDAG since it emits equivalent code and it's NFC for
GlobalISel since the rules involving the relevant predicates are still
rejected by the importer.
llvm-svn: 318102
Similar to r315841, GlobalISel and SelectionDAG require different code for the
common atomic predicates due to differences in the representation.
Even without that, differences in the IR (SDNode vs MachineInstr) require
differences in the C++ predicate.
This patch moves the implementation of the common atomic predicates related to
memory type into tablegen so that it can handle these differences.
It's NFC for SelectionDAG since it emits equivalent code and it's NFC for
GlobalISel since the rules involving the relevant predicates are still
rejected by the importer.
llvm-svn: 318095
Some alias instructions are printed with an extra space after the tab
character. Fix this by skipping that space when the tab character is printed
so that the instructions are aligned with the rest of the code.
Patch by Milos Stojanovic.
Differential Revision: https://reviews.llvm.org/D35946
llvm-svn: 318059
Allow a pattern rewriter to be installed in CodeGenDAGPatterns and use it to
correct situations where SelectionDAG and GlobalISel disagree on
representation. For example, it would rewrite:
(sextload:i32 $ptr)<<unindexedload>><<sextload>><<sextloadi16>
to:
(sext:i32 (load:i16 $ptr)<<unindexedload>>)
I'd have preferred to replace the fragments and have the expansion happen
naturally as part of PatFrag expansion but the type inferencing system can't
cope with loads of types narrower than those mentioned in register classes.
This is because the SDTCisInt's on the sext constrain both the result and
operand to the 'legal' integer types (where legal is defined as 'a register
class can contain the type') which immediately rules the narrower types out.
Several targets (those with only one legal integer type) would then go on to
crash on the SDTCisOpSmallerThanOp<> when it removes all the possible types
for the result of the extend.
Also, improve isObviouslySafeToFold() slightly to automatically return true for
neighbouring instructions. There can't be any re-ordering problems if
re-ordering isn't happenning. We'll need to improve it further to handle
sign/zero-extending loads when the extend and load aren't immediate neighbours
though.
llvm-svn: 317971
Previously, debuginfo-tests was expected to be checked out into
clang/test and then the tests would automatically run as part of
check-clang. This is not a standard workflow for handling
external projects, and it brings with it some serious drawbacks
such as the inability to depend on things other than clang, which
we will need going forward.
The goal of this patch is to migrate towards a more standard
workflow. To ease the transition for build bot maintainers,
this patch tries not to break the existing workflow, but instead
simply deprecate it to give maintainers a chance to update
the build infrastructure.
Differential Revision: https://reviews.llvm.org/D39605
llvm-svn: 317925
This patch adds the ability to include the member function declarations
in the instruction selector class separately from the member bodies.
Defining GET_DAGISEL_DECL macro to any value will only include the member
declarations. To include bodies, define GET_DAGISEL_BODY macro to be the
selector class name. Example:
class FooDAGToDAGISel : public SelectionDAGISel {
// Pull in declarations only.
#define GET_DAGISEL_DECL
#include "FooISelDAGToDAG.inc"
};
// Include the function bodies (with names qualified with the provided
// class name).
#define GET_DAGISEL_BODY FooDAGToDAGISel
#include "FooISelDAGToDAG.inc"
When neither of the two macros are defined, the function bodies are emitted
inline (in the same way as before this patch).
Differential Revision: https://reviews.llvm.org/D39596
llvm-svn: 317903
This should be a trivial change, and I've started using it for generating all
tests at https://github.com/lowrisc/riscv-llvm (i.e. it's been tested in
action quite a lot). Note that the regex does not attempt to match
.cfi_startproc, as I want to ensure compatibility with functions that have the
nounwind attribute.
Differential Revision: https://reviews.llvm.org/D39789
llvm-svn: 317693
Summary:
This makes it very easy to test files that only differ in a constant
value somewhere in the test case.
Reviewers: jlebar, hfinkel, chandlerc, probinson
Reviewed By: probinson
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D39629
llvm-svn: 317572
Patch [1/5] in a series to add assembler/disassembler support for AArch64 SVE
unpredicated ADD/SUB instructions.
Patch by Sander De Smalen.
Reviewed by: rengolin
Differential Revision: https://reviews.llvm.org/D39087
llvm-svn: 317564
Previously, this could end up replacing a vreg like %14 with
[[VREG1]]4, where VREG1 was the match for %1. That's obviously not
correct, though it hasn't actually come up in any tests I've converted
so far.
llvm-svn: 317509
The GlobalISel TableGen backend didn't check for predicates on the
source children. This caused it to generate code for ARM patterns such
as SMLABB or similar, but without properly checking for the sext_16_node
part of the operands. This in turn meant that we would select SMLABB
instead of MLA for simple sequences such as s32 + s32 * s32, which is
wrong (we want a MLA on the full operands, not just their bottom 16
bits).
This patch forces TableGen to skip patterns with predicates on the src
children, so it doesn't generate code for SMLABB and other similar ARM
instructions at all anymore. AArch64 and X86 are not affected.
Differential Revision: https://reviews.llvm.org/D39554
llvm-svn: 317313
This will enable us to prefer VALIGND/Q during shuffle lowering in order to get the extended register encoding space when BWI isn't available. But if we end up not using the extended registers we can switch VPALIGNR for the shorter VEX encoding.
Differential Revision: https://reviews.llvm.org/D39401
llvm-svn: 317122
The importer will now accept nested instructions in the result pattern such as
(ADDWrr $a, (SUBWrr $b, $c)). This is only valid when the nested instruction
def's a single vreg and the parent instruction consumes a single vreg where a
nested instruction is specified. The importer will automatically create a vreg
to connect the two using the type information from the pattern. This vreg will
be constrained to the register classes given in the instruction definitions*.
* REG_SEQUENCE is explicitly rejected because of this. The definition doesn't
constrain to a register class and it therefore needs special handling.
llvm-svn: 317117
The next commit will add support for multi-instruction emission so we need to
start allocating instruction ID's instead of hard-coding them to 0.
llvm-svn: 317057
I need a test that only runs in a reasonable amount of time on systems
that have sparse files. The broadest class of systems that support
sparse files are linux systems. So restricting my test to linux systems
should suffice. This change adds the system-linux feature to llvm-lit so
that it can be required.
Differential Revision: https://reviews.llvm.org/D39482
llvm-svn: 317055
Multi-instruction emission needs to ensure the the instructions are generated
a depth-first fashion. For example:
(ADDWrr (SUBWrr a, b), c)
needs to emit the SUBWrr before the ADDWrr. However, our walk over
TreePatternNode's is highly context sensitive which makes it difficult to append
BuildMIActions in the order we want. To fix this, we now keep track of the
insertion point as we add actions. This will allow multi-insn emission to insert
BuildMI's in the correct place.
The previous commit failed on the Ubuntu bots using GCC 4.8. These bots lack the
const_iterator forms of insert() and emplace() that were added in C++11. As a
result I've switched the const_iterators to iterators.
llvm-svn: 317049
The same bots fail but I believe I know what the issue is now. These bots are
missing the const_iterator versions of insert/emplace/etc. that were introduced
in C++11.
llvm-svn: 317042
Multi-instruction emission needs to ensure the the instructions are generated
a depth-first fashion. For example:
(ADDWrr (SUBWrr a, b), c)
needs to emit the SUBWrr before the ADDWrr. However, our walk over
TreePatternNode's is highly context sensitive which makes it difficult to append
BuildMIActions in the order we want. To fix this, we now keep track of the
insertion point as we add actions. This will allow multi-insn emission to insert
BuildMI's in the correct place.
The previous commit failed on the Ubuntu bots using GCC 4.8. These bots didn't
like a call to emplace(). I've replaced it with insert() to see if it's a quirk
of the C++11 support.
llvm-svn: 317040
Multi-instruction emission needs to ensure the the instructions are generated
a depth-first fashion. For example:
(ADDWrr (SUBWrr a, b), c)
needs to emit the SUBWrr before the ADDWrr. However, our walk over
TreePatternNode's is highly context sensitive which makes it difficult to append
BuildMIActions in the order we want. To fix this, we now keep track of the
insertion point as we add actions. This will allow multi-insn emission to insert
BuildMI's in the correct place.
llvm-svn: 317029
Multi-instruction emission will require that we have separate handling for
the defs between the implicitly created temporaries and the rule outputs.
The former require new temporary vregs while the latter should copy existing
operands. Factor out the implicit def/use renderers to minimize the code
duplication when we implement that.
llvm-svn: 317025
Prepare for multiple instruction emission by allowing BuildMIAction to
search for a suitable matcher that will support mutation.
This patch deliberately neglects to add matchers aside from the root to
preserve NFC. That said, it should be noted that until we support mutations
other than just the opcode the chances of finding a non-root instruction
for which canMutate() is true, is essentially zero. Furthermore in the
presence of multi-instruction emission the chances of finding any
instruction for which canMutate() is true is also zero. Nevertheless, we
can't continue to require that all BuildMIAction's consider the root of the match
to be recyclable due to the risk of recycling it twice in the same rule.
llvm-svn: 317022
Based on similar python tool - utils/shuffle-fuzz.py - this tool extends the ability of it's previous by optionally attaching select instruction to the generated shufflevector instructions.
This was mainly developed to perform exhaustive testing of the X86 AVX512 masked shuffle instructions. But yet it can be used for various other targets.
The general design of the implementation is much modular than the original shuffle_fuzz.py tool, which makes it easier for anyone to extend it further.
Differential Revision: https://reviews.llvm.org/D38031
Change-Id: I0efc2aaa091b61a8a9552311c21cc77916a97111
llvm-svn: 316989
gtest depends on this #define to determine whether it can
use various classes like std::tuple, or whether it has to fall
back to experimental classes in the std::tr1 namespace. The
check in the current version of gtest relies on the value of
the `__cplusplus` macro, but MSVC provides a non-conformant
value of this macro, making it effectively impossible to detect
C++11. In short, LLVM compiled with MSVC has been silently
using the tr1 versions of several classes since the beginning of
time.
This would normally be pretty benign, except that in the latest
preview of MSVC they have marked all of the tr1 classes
deprecated, so it spews thousands of warnings.
llvm-svn: 316798
When multi-instruction emission is supported, it will no longer be guaranteed
that every BuildMIAction has a corresponding matched instruction. BuildMIAction
should support not having one to cover the case where a rule produces more
instructions than it matched.
llvm-svn: 316463
Ideally, we should compare 32- and 64-bit versions to see if the
ret line is the only difference and then insert the regex only
in that case. But this is a quick hack to avoid a bunch of noise
as existing tests are updated.
llvm-svn: 316443
