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
register allocation.
Process all of the clobber lists at the end of the function, marking the
registers as used in MachineRegisterInfo.
This is necessary in case the calls clobber callee-saved registers (sic).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105473 91177308-0d34-0410-b5e6-96231b3b80d8
replace an OpA with a widened OpB, it is possible to get new uses of OpA due to CSE
when recursively updating nodes. Since OpA has been processed, the new uses are
not examined again. The patch checks if this occurred and it it did, updates the
new uses of OpA to use OpB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105453 91177308-0d34-0410-b5e6-96231b3b80d8
VECTOR_SHUFFLEs to REG_SEQUENCE instructions. The standard ISD::BUILD_VECTOR
node corresponds closely to REG_SEQUENCE but I couldn't use it here because
its operands do not get legalized. That is pretty awful, but I guess it
makes sense for other targets. Instead, I have added an ARM-specific version
of BUILD_VECTOR that will have its operands properly legalized.
This fixes the rest of Radar 7872877.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105439 91177308-0d34-0410-b5e6-96231b3b80d8
Check that all the instructions are in the same basic block, that the
EXTRACT_SUBREGs write to the same subregs that are being extracted, and that
the source and destination registers are in the same regclass. Some of
these constraints can be relaxed with a bit more work. Jakob suggested
that the loop that checks for subregs when NewSubIdx != 0 should use the
"nodbg" iterator, so I made that change here, too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105437 91177308-0d34-0410-b5e6-96231b3b80d8
A temporary flag -arm-tail-calls defaults to off,
so there is no functional change by default.
Intrepid users may try this; simple cases work
but there are bugs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105413 91177308-0d34-0410-b5e6-96231b3b80d8
registers it defines then interfere with an existing preg live range.
For instance, if we had something like these machine instructions:
BB#0
... = imul ... EFLAGS<imp-def,dead>
test ..., EFLAGS<imp-def>
jcc BB#2 EFLAGS<imp-use>
BB#1
... ; fallthrough to BB#2
BB#2
... ; No code that defines EFLAGS
jcc ... EFLAGS<imp-use>
Machine sink will come along, see that imul implicitly defines EFLAGS, but
because it's "dead", it assumes that it can move imul into BB#2. But when it
does, imul's "dead" imp-def of EFLAGS is raised from the dead (a zombie) and
messes up the condition code for the jump (and pretty much anything else which
relies upon it being correct).
The solution is to know which pregs are live going into a basic block. However,
that information isn't calculated at this point. Nor does the LiveVariables pass
take into account non-allocatable physical registers. In lieu of this, we do a
*very* conservative pass through the basic block to determine if a preg is live
coming out of it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105387 91177308-0d34-0410-b5e6-96231b3b80d8
expansion is the same as that used by LegalizeDAG.
The resulting code sucks in terms of performance/codesize on x86-32 for a
64-bit operation; I haven't looked into whether different expansions might be
better in general.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105378 91177308-0d34-0410-b5e6-96231b3b80d8
spills and reloads.
This means that a partial define of a register causes a reload so the other
parts of the register are preserved.
The reload can be prevented by adding an <imp-def> operand for the full
register. This is already done by the coalescer and live interval analysis where
relevant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105369 91177308-0d34-0410-b5e6-96231b3b80d8
register updates.
These operands tell the spiller that the other parts of the partially defined
register are don't-care, and a reload is not necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105361 91177308-0d34-0410-b5e6-96231b3b80d8
instruction defines subregisters.
Any existing subreg indices on the original instruction are preserved or
composed with the new subreg index.
Also substitute multiple operands mentioning the original register by using the
new MachineInstr::substituteRegister() function. This is necessary because there
will soon be <imp-def> operands added to non read-modify-write partial
definitions. This instruction:
%reg1234:foo = FLAP %reg1234<imp-def>
will reMaterialize(%reg3333, bar) like this:
%reg3333:bar-foo = FLAP %reg333:bar<imp-def>
Finally, replace the TargetRegisterInfo pointer argument with a reference to
indicate that it cannot be NULL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105358 91177308-0d34-0410-b5e6-96231b3b80d8
backends and removes the virtual declaration. With that out of the way
I should be able to cleanup one backend at a time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105321 91177308-0d34-0410-b5e6-96231b3b80d8
x86 backend currently doesn't know how to handle them.
This doesn't really fix anything because LegalizeTypes doesn't know how to
handle them either. We do get a better error message, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105305 91177308-0d34-0410-b5e6-96231b3b80d8
The comment about ordering of subreg indices is no longer true.
This exposed a bug in the new substVirtReg method that is also fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105294 91177308-0d34-0410-b5e6-96231b3b80d8
handle structs passed by value via an extract/insert pair, as a bitcast
won't work on a struct. rdar://7742824
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105280 91177308-0d34-0410-b5e6-96231b3b80d8
the newly created allocas may be used by inlined calls, so these
need to have their tail call flags cleared. Fixes PR7272.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105255 91177308-0d34-0410-b5e6-96231b3b80d8
that are too large. This causes the freebsd bootloader to be too
large apparently.
It's unclear if this should be an -Os or -Oz thing. Thoughts welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105228 91177308-0d34-0410-b5e6-96231b3b80d8
shouldn't have a TargetLoweringInfo member. And FunctionLoweringInfo::set
doesn't needs its EnableFastISel argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105101 91177308-0d34-0410-b5e6-96231b3b80d8
were overspecified when inheriting sub-subregisters, for instance:
R0Q:subreg_even32 = R0Q:subreg_32bit = R0Q:subreg_even:subreg_32bit.
This meant that composeSubRegIndices(subreg_even, subreg_32bit) was ambiguous.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105063 91177308-0d34-0410-b5e6-96231b3b80d8
implementation that is correct for most targets. Tablegen will override where
needed.
Add MachineOperand::subst{Virt,Phys}Reg methods that correctly handle existing
subreg indices when sustituting registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104985 91177308-0d34-0410-b5e6-96231b3b80d8
optimization level.
This only really affects llc for now because both the llvm-gcc and clang front
ends override the default register allocator. I intend to remove that code later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104904 91177308-0d34-0410-b5e6-96231b3b80d8
and change llvm::sys::RunInterruptHandlers to call that function directly
instead of calling SignalHandler, because the rest of SignalHandler
invokes side effects which aren't appropriate, including raising the
signal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104896 91177308-0d34-0410-b5e6-96231b3b80d8
the wrong level. Clients which need to leave the stream open but
which still require the bitcode bits to be on disk should call
flush themselves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104885 91177308-0d34-0410-b5e6-96231b3b80d8
should fall through to the 'H' case, but instead 'Q' was falling through to 'R'
so that it would do the wrong thing for a big-endian ARM target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104883 91177308-0d34-0410-b5e6-96231b3b80d8
it to be the caller's responsibility to provide a stream in binary
mode. This fixes a layering violation and avoids an outs() call.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104878 91177308-0d34-0410-b5e6-96231b3b80d8
