flag argument to addReg is not the same format as flags attached
to MachineOperand, although both have the same info. I don't
think this actually mattered; the bootstrap failure did not
reproduce on the next run anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106049 91177308-0d34-0410-b5e6-96231b3b80d8
SimpleRegisterCoalescing::JoinIntervals() uses CoalescerPair to determine if a
copy is coalescable, and in very rare cases it can return true where LHS is not
live - the coalescable copy can come from an alias of the physreg in LHS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106021 91177308-0d34-0410-b5e6-96231b3b80d8
combined to an insert_subreg, i.e., where the destination register is larger
than the source. We need to check that the subregs can be composed for that
case in a symmetrical way to the case when the destination is smaller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106004 91177308-0d34-0410-b5e6-96231b3b80d8
Early clobbers defining a virtual register were first alocated to a physreg and
then processed as a physreg EC, spilling the virtreg.
This fixes PR7382.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105998 91177308-0d34-0410-b5e6-96231b3b80d8
Given a copy instruction, CoalescerPair can determine which registers to
coalesce in order to eliminate the copy. It deals with all the subreg fun to
determine a tuple (DstReg, SrcReg, SubIdx) such that:
- SrcReg is a virtual register that will disappear after coalescing.
- DstReg is a virtual or physical register whose live range will be extended.
- SubIdx is 0 when DstReg is a physical register.
- SrcReg can be joined with DstReg:SubIdx.
CoalescerPair::isCoalescable() determines if another copy instruction is
compatible with the same tuple. This fixes some NEON miscompilations where
shuffles are getting coalesced as if they were copies.
The CoalescerPair class will replace a lot of the spaghetti logic in JoinCopy
later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105997 91177308-0d34-0410-b5e6-96231b3b80d8
replacing the overly conservative checks that I had introduced recently to
deal with correctness issues. This makes a pretty noticable difference
in our testcases where reg_sequences are used. I've updated one test to
check that we no longer emit the unnecessary subreg moves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105991 91177308-0d34-0410-b5e6-96231b3b80d8
containing the target address, an input, into an output. I don't
think this actually broke anything on x86 (it does on ARM), but
it's wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105986 91177308-0d34-0410-b5e6-96231b3b80d8
immediate" operands. These functions have so far only been used for VMOV
but they also apply to other NEON instructions with modified immediate
operands. No functional changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105969 91177308-0d34-0410-b5e6-96231b3b80d8
- Rename ExactHazardRecognizer to PostRAHazardRecognizer and move its header to include to allow targets to extend it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105959 91177308-0d34-0410-b5e6-96231b3b80d8
symbols as declarations in the X86 backend. This would manifest
on darwin x86-32 as errors like this with -fvisibility=hidden:
symbol '__ZNSbIcED1Ev' can not be undefined in a subtraction expression
This fixes PR7353.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105954 91177308-0d34-0410-b5e6-96231b3b80d8
clean-up to a catch-all after inlining, take into account that there could be
filter IDs as well. The presence of filters don't mean that the selector catches
anything. It's just metadata information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105872 91177308-0d34-0410-b5e6-96231b3b80d8
i64 and f64 types, but now it also handle Neon vector types, so the f64 result
of VMOVDRR may need to be converted to a Neon type. Radar 8084742.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105845 91177308-0d34-0410-b5e6-96231b3b80d8
the machine instruction representation of the immediate value to be encoded
into an integer with similar fields as the actual VMOV instruction. This makes
things easier for the disassembler, since it can just stuff the bits into the
immediate operand, but harder for the asm printer since it has to decode the
value to be printed. Testcase for the encoding will follow later when MC has
more support for ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105836 91177308-0d34-0410-b5e6-96231b3b80d8
dbg_value immediately follows a sequence of ldr/str instructions that should
be combined into an ldm/stm and is the last instruction in the block, then
combine may end up being skipped.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105758 91177308-0d34-0410-b5e6-96231b3b80d8
This is a bit of a hack to make inline asm look more like call instructions.
It would be better to produce correct dead flags during isel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105749 91177308-0d34-0410-b5e6-96231b3b80d8
%reg1025 = <sext> %reg1024
...
%reg1026 = SUBREG_TO_REG 0, %reg1024, 4
into this:
%reg1025 = <sext> %reg1024
...
%reg1027 = EXTRACT_SUBREG %reg1025, 4
%reg1026 = SUBREG_TO_REG 0, %reg1027, 4
The problem here is that SUBREG_TO_REG is there to assert that an implicit zext
occurs. It doesn't insert a zext instruction. If we allow the EXTRACT_SUBREG
here, it will give us the value after the <sext>, not the original value of
%reg1024 before <sext>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105741 91177308-0d34-0410-b5e6-96231b3b80d8
the same condition, it's important to make sure they are scheduled together
to avoid forming multiple IT blocks. I'm adding a pre-regalloc pass that forms
IT blocks early (by re-scheduling instructions and split basic blocks) to
attempt to fix this. This is not turned on by default since I am not sure this
is the right fix.
Another issue is llvm selects are modeled as two-address conditional moves.
This can be very bad when the copies before the conditional moves are not
coalesced away. Teach IT formation pass to move the copies above the IT block
(when legal) to avoid breaking the IT block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105669 91177308-0d34-0410-b5e6-96231b3b80d8
instruction. Added the 64-bit version "jrcxz" so it is recognized and also
added the checks for incorrect uses of "jcxz" in 64-bit mode and "jrcxz" in
32-bit mode. Still to do is to correctly handle the encoding of the
instruction adding the Address-size override prefix byte, 0x67, when the width
of the count register is not the same as the mode the machine is running in.
Which for example means the encoding of "jecxz" depends if you are assembling
as a 32-bit target or a 64-bit target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105661 91177308-0d34-0410-b5e6-96231b3b80d8
- This can give substantial speedups in the delta process for inputs we can construct dependency information for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105612 91177308-0d34-0410-b5e6-96231b3b80d8
- change isShuffleMaskLegal to show that all shuffles with 32-bit and 64-bit
elements are legal
- the Neon shuffle instructions do not support 64-bit elements, but we were
not checking for that before lowering shuffles to use them
- remove some 64-bit element vduplane patterns that are no longer needed
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105586 91177308-0d34-0410-b5e6-96231b3b80d8
scrounging through SCEVUnknown contents and SCEVNAryExpr operands;
instead just do a simple deterministic comparison of the precomputed
hash data.
Also, since this is more precise, it eliminates the need for the slow
N^2 duplicate detection code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105540 91177308-0d34-0410-b5e6-96231b3b80d8
encapsulation to force the users of these classes to know about the internal
data structure of the Operands structure. It also can lead to errors, like in
the MSIL writer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105539 91177308-0d34-0410-b5e6-96231b3b80d8
In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105524 91177308-0d34-0410-b5e6-96231b3b80d8
there could be multiple subexpressions within a single expansion which
require insert point adjustment. This fixes PR7306.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105510 91177308-0d34-0410-b5e6-96231b3b80d8
