makes calls a little bit more consistent and allows easy removal of the
specializations in the future. Convert all callers to the templated functions.
llvm-svn: 99838
"the bigstack patch for SPU, with testcase. It is essentially the patch committed as 97091, and reverted as 97099, but with the following additions:
-in vararg handling, registers are marked to be live, to not confuse the register scavenger
-function prologue and epilogue are not emitted, if the stack size is 16. 16 means it is empty - there is only the register scavenger emergency spill slot, which is not used as there is no stack."
llvm-svn: 99819
These instructions use byte index in a control vector (M:Vm) to lookup byte
values in a table and generate a new vector (D:Vd). The table is specified via
a list of vectors, which can be:
{Dn}
{Dn D<n+1>}
{Dn D<n+1> D<n+2>}
{Dn D<n+1> D<n+2> D<n+3>}
llvm-svn: 99789
input to be v8i8 or v16i8, which buildvectors get canonicalized to.
This allows the patterns that were previously using a bare 'vnot' to
match, before they couldn't.
llvm-svn: 99754
it as the format for the appropriate N3V*SL*<> classes. These instructions
require special handling of the M:Vm field which encodes the restricted Dm and
the lane index within Dm.
Examples are A8.6.325 VMLA, VMLAL, VMLS, VMLSL (by scalar):
vmlal.s32 q3, d2, d10[0]
llvm-svn: 99690
through to the generic version. The generic functions use STR/LDR, but T2
needs the t2STR/t2LDR instead so we get the addressing mode correct.
llvm-svn: 99678
to encode the byte location of the extracted result in the concatenation of the
operands, from the least significant end.
Modify VEXTd and VEXTq classes to use the format.
llvm-svn: 99659
follow the N3RegFrm's operand order of D:Vd N:Vn M:Vm. The operand order of
N3RegVShFrm is D:Vd M:Vm N:Vn (notice that M:Vm is the first src operand).
Add a parent class N3Vf which requires passing a Format argument and which the
N3V class is modified to inherit from. N3V class represents the "normal"
3-Register NEON Instructions with N3RegFrm.
Also add a multiclass N3VSh_QHSD to represent clusters of NEON 3-Register Shift
Instructions and replace 8 invocations with it.
llvm-svn: 99655
Examples are VABA (Vector Absolute Difference and Accumulate), VABAL (Vector
Absolute Difference and Accumulate Long), and VABD (Vector Absolute Difference).
llvm-svn: 99628
dispatch to the appropriate routines to handle the different interpretations of
the shift amount encoded in the imm6 field. The Vd, Vm fields are interpreted
the same between the two, though.
See, for example, A8.6.367 VQSHL, VQSHLU (immediate) for N2RegVShLFrm format and
A8.6.368 VQSHRN, VQSHRUN for N2RegVShRFrm format.
llvm-svn: 99590
On Nehalem and newer CPUs there is a 2 cycle latency penalty on using a register
in a different domain than where it was defined. Some instructions have
equvivalents for different domains, like por/orps/orpd.
The SSEDomainFix pass tries to minimize the number of domain crossings by
changing between equvivalent opcodes where possible.
This is a work in progress, in particular the pass doesn't do anything yet. SSE
instructions are tagged with their execution domain in TableGen using the last
two bits of TSFlags. Note that not all instructions are tagged correctly. Life
just isn't that simple.
The SSE execution domain issue is very similar to the ARM NEON/VFP pipeline
issue handled by NEONMoveFixPass. This pass may become target independent to
handle both.
llvm-svn: 99524
addl $12, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
jmpl *__Block_deallocator-L1$pb(%esi) # TAILCALL
The problem is the global base register is assigned GR32 register class. TCRETURNmi needs the registers making up the address mode to have the GR32_TC register class.
The *proper* fix is for X86DAGToDAGISel::getGlobalBaseReg() to return a copy from the global base register of the machine function rather than returning the register itself. But that has the potential of causing it to be coalesced to a more restrictive register class: GR32_TC. It can introduce additional copies and spills. For something as important the PIC base, it's not worth it especially since this is not an issue on 64-bit.
llvm-svn: 99455
Benjamin Kramer