Summary:
This is NFC but prevents assertions when PartialMappingIdx is tablegen-erated.
The assumptions were:
1) FirstGPR is 0
2) FirstGPR is the first of the First* enumerators.
GPR32 is changed to 1 to demonstrate that assumption #1 is fixed. #2 will
be covered by a subsequent patch that tablegen-erates information and swaps
the order of GPR and FPR as a side effect.
Depends on D27336
Reviewers: ab, t.p.northover, qcolombet
Subscribers: aemerson, rengolin, vkalintiris, dberris, rovka, llvm-commits
Differential Revision: https://reviews.llvm.org/D27337
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288812 91177308-0d34-0410-b5e6-96231b3b80d8
When we see a non flag-setting instruction for which only the flag-setting
version is available in Thumb1, we should give a better error message than
"invalid instruction".
Differential Revision: https://reviews.llvm.org/D27414
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288805 91177308-0d34-0410-b5e6-96231b3b80d8
Check if a build_vector node includes a repeated constant pattern and replace it with a broadcast of that pattern.
For example:
"build_vector <0, 1, 2, 3, 0, 1, 2, 3>" would be replaced by "broadcast <0, 1, 2, 3>"
Differential Revision: https://reviews.llvm.org/D26802
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288804 91177308-0d34-0410-b5e6-96231b3b80d8
This is the final patch in the series of patches that improves
BUILD_VECTOR handling on PowerPC. This adds a few peephole optimizations
to remove redundant instructions. It also adds a large test case which
encompasses a large set of code patterns that build vectors - this test
case was the motivator for this series of patches.
Differential Revision: https://reviews.llvm.org/D26066
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288800 91177308-0d34-0410-b5e6-96231b3b80d8
a hilarious bug and fix it.
We somehow were never verifying the RefSCCs newly formed when
splitting an existing one apart, and when verifying them we weren't
really checking the SCC indices mapping effectively.
If we had been, it would have been blindingly obvious that right after
putting something int `RC.SCCs` we should update `RC.SCCIndices` instead
of `SCCIndices` which we were about to clear and rebuild anyways. =[
Anyways, this is thoroughly covered by existing tests now that we
actually verify things properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288795 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch makes sure FirstCSPop and MBBI never point to DBG_VALUE instructions, which affected the code generated.
Reviewers: mkuper, aprantl, MatzeB
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27343
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288794 91177308-0d34-0410-b5e6-96231b3b80d8
Just using InstIterator, simpler loop structures, and making better use
of the visit callback infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288790 91177308-0d34-0410-b5e6-96231b3b80d8
This pattern turned a vector sqrt/rcp/rsqrt operation of sse_load_f32/f64 into the the scalar instruction for the operation and put undef into the upper bits. For correctness, the resulting code should still perform the sqrt/rcp/rsqrt on the upper bits after the load is extended since that's what the operation asked for. Particularly in the case where the upper bits are 0, in that case we need calculate the sqrt/rcp/rsqrt of the zeroes and keep the result in the upper-bits. This implies we should be using the packed instruction still.
The only test case for this pattern is one I just added so there was no coverage of this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288784 91177308-0d34-0410-b5e6-96231b3b80d8
This occurs due to a pattern that uses sse_load_f32/f64 with vector sqrt/rcp/rsqrt operations and turns them into scalar instructions. Perhaps for the case were the upper bits come from undef this is ok. I believe a (vzmovl load64) would do the same thing but those seems to become vzload instead and selectScalarSSELoad doesn't handle that today. In that case we should be performing the vector operation on the zeros in the upper bits which is not equivalent to using a scalar instruction.
I will remove this pattern in a follow up patch. There appears to be no other test content for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288783 91177308-0d34-0410-b5e6-96231b3b80d8
The intrinsics are supposed to pass the upper bits straight through to their output register. This means we need to make sure we still perform the 128-bit load to get those upper bits to pass to give to the instruction since the memory form of the instruction only reads 32 or 64 bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288781 91177308-0d34-0410-b5e6-96231b3b80d8
The sqrtsd instruction only loads 64-bits and writes bits 63:0 with the sqrt result. Bits 127:64 are preserved in the destination register. The semantics of the intrinsic indicate bits 127:64 should come from the intrinsic argument which in this case is a 128-bit load. So the generated code should have a 128-bit load and use a register form of sqrtsd.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288780 91177308-0d34-0410-b5e6-96231b3b80d8
The intrinsic takes one argument, the lower bits are affected by the operation and the upper bits should be passed through. The instruction itself takes two operands, the high bits of the first operand are passed through and the low bits of the second operand are modified by the operation. To match this to the intrinsic we should pass the single intrinsic input to both operands.
I had to remove the stack folding test for these instructions since they depended on the incorrect behavior. The same register is now used for both inputs so the load can't be folded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288779 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the starting support for encoding data from the MachO __DWARF segment. The first section supported is the __debug_str section because it is the simplest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288774 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch removes the scalar logical operation alias instructions. We can just use reg class copies and use the normal packed instructions instead. This removes the need for putting these instructions in the execution domain fixing tables as was done recently.
I removed the loadf64_128 and loadf32_128 patterns as DAG combine creates a narrower load for (extractelt (loadv4f32)) before we ever get to isel.
I plan to add similar patterns for AVX512DQ in a future commit to allow use of the larger register class when available.
Reviewers: spatel, delena, zvi, RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27401
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288771 91177308-0d34-0410-b5e6-96231b3b80d8
It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool.
This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories.
This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288770 91177308-0d34-0410-b5e6-96231b3b80d8
Integers are expressed in the lattice via constant ranges. They can never be represented by constants or not-constants; those are reserved for non-integer types. This code has been dead for literaly years.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288767 91177308-0d34-0410-b5e6-96231b3b80d8
Extracting a helper function out of solveBlockValue makes the contract around the cache much easier to understand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288766 91177308-0d34-0410-b5e6-96231b3b80d8
This completes a small series of patches to hide the stateful updates of LVILatticeVal from the consuming code. The only remaining stateful API is mergeIn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288765 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We recently introduced a feature that enforce at link-time that the
LLVM headers used by a clients are matching the ABI setting of the
LLVM library linked to.
However for clients that are using only headers from ADT and promise
they won't call into LLVM, this is forcing to link libSupport. This
new flag is intended to provide a way to configure LLVM with this
promise for such client.
Reviewers: bob.wilson, compnerd
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D27432
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288754 91177308-0d34-0410-b5e6-96231b3b80d8
The structured CFG is just an aid to inserting exec
mask modification instructions, once that is done
we don't really need it anymore. We also
do not analyze blocks with terminators that
modify exec, so this should only be impacting
true branches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288744 91177308-0d34-0410-b5e6-96231b3b80d8
clang -target arm deprecated-asm.s -c
deprecated-asm.s:30:9: warning: use of SP or PC in the list is deprecated
stmia r4!, {r12-r14}
We have to have an option what can disable it.
Patched by Yin Ma!
Reviewers: joey, echristo, weimingz
Subscribers: llvm-commits, aemerson
Differential Revision: https://reviews.llvm.org/D27219
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288734 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
There are two cases handled here:
1) a branch on undef
2) a switch with an undef condition.
Both cases are currently handled by ResolvedUndefsIn. If we have
a branch on undef, we force its value to false (which is trivially
foldable). If we have a switch on undef, we force to the first
constant (which is also foldable).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288725 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The code we use to read PDBs assumed that streams we ask it to read exist, and would read memory outside a vector and crash if this wasn't the case. This would, for example, cause llvm-pdbdump to crash on PDBs generated by lld. This patch handles such cases more gracefully: the PDB reading code in LLVM now reports errors when asked to get a stream that is not present, and llvm-pdbdump will report missing streams and continue processing streams that are present.
Reviewers: ruiu, zturner
Subscribers: thakis, amccarth
Differential Revision: https://reviews.llvm.org/D27325
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288722 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
