Several buildbots encountered a crash in tablegen when building this commit.
Reverting while I investigate the cause.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292136 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Adds a RegisterBank tablegen class that can be used to declare the register
banks and an associated tablegen pass to generate the necessary code.
Reviewers: t.p.northover, ab, rovka, qcolombet
Subscribers: aditya_nandakumar, rengolin, kristof.beyls, vkalintiris, mgorny, dberris, llvm-commits, rovka
Differential Revision: https://reviews.llvm.org/D27338
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292132 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r291973.
The test fails in a Release build with LLVM_BUILD_GLOBAL_ISEL enabled.
AFAICT, llc segfaults. I'll add a few more details to the original
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292061 91177308-0d34-0410-b5e6-96231b3b80d8
Correctly populating Machine PHIs relies on knowing exactly how the IR level
CFG was lowered to MachineIR. This needs to be tracked by any translation
phases that meddle (currently only SwitchInst handling).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291973 91177308-0d34-0410-b5e6-96231b3b80d8
With some minor manual fixes for using function_ref instead of
std::function. No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291904 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The register bank is now entirely initialized in the constructor. However,
we still have the hardcoded number of register classes which will be
dealt with in the TableGen patch (D27338) since we do not have access
to this information to resolve this at this stage. The number of register
classes is known to the TRI and to TableGen but the RegisterBank
constructor is too early for the former and too late for the latter.
This will be fixed when the data is tablegen-erated.
Reviewers: t.p.northover, ab, rovka, qcolombet
Subscribers: aditya_nandakumar, kristof.beyls, vkalintiris, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D27809
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291770 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Refactor the RegisterBank initialization to use static data. This requires
GlobalISel implementations to rewrite calls to createRegisterBank() and
addRegBankCoverage() into a call to setRegBankData().
Out of tree targets can use diff 4 of D27807
(https://reviews.llvm.org/D27807?id=84117) to have addRegBankCoverage() dump
the register classes and other data that needs to be provided to
setRegBankData(). This is the method that was used to generate the static data
in this patch.
Tablegen-eration of this static data will follow after some refactoring.
Reviewers: t.p.northover, ab, rovka, qcolombet
Subscribers: aditya_nandakumar, kristof.beyls, vkalintiris, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D27807
Differential Revision: https://reviews.llvm.org/D27808
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291768 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I've noticed that these assertions don't trigger when the condition is false.
The problem is that the DEBUG(x) macro only executes x when the pass is
emitting debug output via the -debug and -debug-only=registerbankinfo command
line arguments.
Debug builds should always execute the assertions so use '#ifndef NDEBUG' instead.
Also removed an assertion that is only true the first time it's tested. <Target>RegisterBankInfo's constructor will re-use register banks causing them to be valid on subsequent tests. That
assertion will fail on the first test too in the near future.
Reviewers: t.p.northover, ab, rovka, qcolombet
Subscribers: dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D28358
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291235 91177308-0d34-0410-b5e6-96231b3b80d8
To make this work, pointers from the MachineBasicBlock to the LLVM-IR-level
basic blocks need to be initialized, as the AsmPrinter uses this link to be
able to print out labels for the basic blocks that are address-taken.
Most of the changes in this commit are about adapting existing tests to include
the basic block name that is now printed out in the MIR format, now that the
name becomes available as the link to the LLVM-IR basic block is initialized.
The relevant test change for the functionality added in this patch are the
added "(address-taken)" strings in
test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll.
Differential Revision: https://reviews.llvm.org/D28123
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291105 91177308-0d34-0410-b5e6-96231b3b80d8
This is going to be needed to be able to constraint register class on
target specific instruction while the RegBankSelect pass did not run
yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290375 91177308-0d34-0410-b5e6-96231b3b80d8
Move the logic to constraint register from InstructionSelector to a
utility function. It will be required by other passes in the GlobalISel
pipeline.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290374 91177308-0d34-0410-b5e6-96231b3b80d8
Add the minimal support necessary to select a function that returns the sum of
two i32 values.
This includes some support for argument/return lowering of i32 values through
registers, as well as the handling of copy and add instructions throughout the
GlobalISel pipeline.
Differential Revision: https://reviews.llvm.org/D26677
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289940 91177308-0d34-0410-b5e6-96231b3b80d8
The IRTranslator uses an additional block before the LLVM-IR entry block
to perform all the ABI lowering and the constant hoisting. Thus, this
block is the actual entry block and it falls through the LLVM-IR entry
block. However, with such representation, we end up with two basic
blocks that are not maximal.
Therefore, this patch adds a bit of canonicalization by merging both the
LLVM-IR entry block and the ABI lowering/constants hoisting into one
block, making the resulting block more likely to be maximal (indeed the
LLVM-IR entry block might not have been maximal).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289891 91177308-0d34-0410-b5e6-96231b3b80d8
Supporting them properly is a reasonably complex chunk of work, so to allow bot
testing before then we should at least be able to fall back to DAG ISel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289150 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantExpr instances were emitting code into the current block rather than
the entry block. This meant they didn't necessarily dominate all uses, which is
clearly wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288985 91177308-0d34-0410-b5e6-96231b3b80d8
Having to ask the MIRBuilder for the current function is a little awkward, and
I'm intending to improve how that's threaded through anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288983 91177308-0d34-0410-b5e6-96231b3b80d8
MachineIRBuilder had weird before/after and beginning/end flags for the insert
point. Unfortunately the non-default means that instructions will be inserted
in reverse order which is almost never what anyone wants.
Really, I think we just want (like IRBuilder has) the ability to insert at any
C++ iterator-style point (i.e. before any instruction or before MBB.end()). So
this fixes MIRBuilders to behave like IRBuilders in this respect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288980 91177308-0d34-0410-b5e6-96231b3b80d8
We were rounding size in bits down rather than up, leading to 0-sized slots for
i1 (assert!) and bugs for other types not byte-aligned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288848 91177308-0d34-0410-b5e6-96231b3b80d8
There were two problems:
+ AArch64 was reusing random data from its binary op tables, which is
complete nonsense for G_SEQUENCE.
+ Even when AArch64 gave up and said it couldn't handle G_SEQUENCE,
the generic code asserted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288836 91177308-0d34-0410-b5e6-96231b3b80d8
It'll almost immediately fail because it always tries to half/double the size
until it finds a legal one. Unfortunately, this triggers an assertion
preventing the DAG fallback from being possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288834 91177308-0d34-0410-b5e6-96231b3b80d8
The function used to finish off PHIs by adding the relevant basic blocks can
fail if we're aborting and still don't actually have the needed
MachineBasicBlocks. So avoid trying in that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288727 91177308-0d34-0410-b5e6-96231b3b80d8
When the entry block was empty after arg lowering, we were always placing
constants at the end. This is probably hamrless while translating the same
block, but horribly wrong once its terminator has been translated. So switch to
inserting at the beginning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288720 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it more similar to the floating-point constant, and also allows for
larger constants to be translated later. There's no real functional change in
this patch though, just syntax updates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288712 91177308-0d34-0410-b5e6-96231b3b80d8
Returning 0 (NoReg) from getOrCreateVReg leads to unexpected situations later
in the translation. It's better to return a valid (if undefined) register and
let the rest of the instruction carry on as planned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288709 91177308-0d34-0410-b5e6-96231b3b80d8
This function seems target-independent so far: all the target-specific behaviour
is isolated in the CCAssignFn and the ValueHandler (which we're also extracting
into the generic CallLowering).
The intention is to use this in the ARM backend.
Differential Revision: https://reviews.llvm.org/D27045
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288658 91177308-0d34-0410-b5e6-96231b3b80d8
Recommitting r288293 with some extra fixes for GlobalISel code.
Most of the exception handling members in MachineModuleInfo is actually
per function data (talks about the "current function") so it is better
to keep it at the function instead of the module.
This is a necessary step to have machine module passes work properly.
Also:
- Rename TidyLandingPads() to tidyLandingPads()
- Use doxygen member groups instead of "//===- EH ---"... so it is clear
where a group ends.
- I had to add an ugly const_cast at two places in the AsmPrinter
because the available MachineFunction pointers are const, but the code
wants to call tidyLandingPads() in between
(markFunctionEnd()/endFunction()).
Differential Revision: https://reviews.llvm.org/D27227
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288405 91177308-0d34-0410-b5e6-96231b3b80d8
This patch updates a bunch of places where add_dependencies was being explicitly called to add dependencies on intrinsics_gen to instead use the DEPENDS named parameter. This cleanup is needed for a patch I'm working on to add a dependency debugging mode to the build system.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287206 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r286962.
We want to avoid depending on SelectionDAG, and AddLandingPadInfo
lives in CodeGen now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287168 91177308-0d34-0410-b5e6-96231b3b80d8
They're not SelectionDAG- or FunctionLoweringInfo-specific. They
are, however, specific to building MMI from IR.
We could make them members, but it's nice having MMI be a "simple" data
structure and this logic kept separate.
This also lets us reuse them from GlobalISel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287167 91177308-0d34-0410-b5e6-96231b3b80d8
r286407 has introduced calls to llvm::AddLandingPadInfo, which lives in the
SelectionDAG component. Add it to LLVMBuild to avoid linker failures on Linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286962 91177308-0d34-0410-b5e6-96231b3b80d8
Pretty bare-bones support for exception handling (no weird MSVC stuff, no SjLj
etc), but it should get things going.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286407 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There are two variables here that break. This change constrains both of them to
debug builds (via DEBUG() or #ifndef NDEBUG).
Reviewers: bkramer, t.p.northover
Subscribers: mehdi_amini, vkalintiris
Differential Revision: https://reviews.llvm.org/D26421
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286300 91177308-0d34-0410-b5e6-96231b3b80d8
After instruction selection we perform some checks on each VReg just before
discarding the type information. These checks were assertions before, but that
breaks the fallback path so this patch moves the logic into the main flow and
reports a better error on failure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286289 91177308-0d34-0410-b5e6-96231b3b80d8
Erasing reverse_iterators is problematic; iterate manually.
While there, keep track of the range of inserted instructions.
It can miss instructions inserted elsewhere, but those are harder
to track.
Differential Revision: http://reviews.llvm.org/D22924
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286272 91177308-0d34-0410-b5e6-96231b3b80d8
