operations in x87 code.

llvm-svn: 108098

llvm-svn: 108097

We are generating movaps for all XMM register copies, including scalar
floating point values. This is known to be at least as good as movss and movsd
for all known architectures up to and including Nehalem because it avoids a
partial register stall.

The SSEDomainFix pass will switch movaps to movdqa when appropriate (i.e., when
operands come from the integer unit). We don't now that switching movaps to
movapd has any benefit.

The same applies to andps -> pand.

llvm-svn: 108096

Targets must now implement TargetInstrInfo::copyPhysReg instead. There is no
longer a default implementation forwarding to copyRegToReg.

llvm-svn: 108095

llvm-svn: 108094

The first one was used just to call isSafeToMoveRegClassDefs. In
general, using a more specific reg class is better, in practice only
x86 implements that method and the results are always the same.

The second one is in FindFreeRegister and is used to check if a register
is in a register class, a much more direct call to contains is better as
it should cover more cases and is faster.

llvm-svn: 108093

llvm-svn: 108092

llvm-svn: 108091

assert()s, switching to void-casts. Removed an unneeded Compiler.h include as
a result. There are two other uses in LLVM, but they're not due to assert()s,
so I've left them alone.

llvm-svn: 108088

llvm-svn: 108087

llvm-svn: 108086

probably try and switch more of these if I can.

llvm-svn: 108085

llvm-svn: 108084

llvm-svn: 108083

llvm-svn: 108082

llvm-svn: 108081

llvm-svn: 108080

llvm-svn: 108079

llvm-svn: 108078

llvm-svn: 108077

llvm-svn: 108076

Use a COPY instruction instead for register copies, or TII::copyPhysReg() after
COPY instructions are lowered.

Targets should implement copyPhysReg instead of copyRegToReg.

llvm-svn: 108075

Don't try a cross-class copy. That is very unlikely anywy since return value
registers are usually register class friendly. (%EAX, %XMM0, etc).

llvm-svn: 108074

This doesn't change the behavior of SelectBitcast for X86.

llvm-svn: 108073

correct alignment information, which simplifies ExpandRes_VAARG a bit.

The patch introduces a new alignment information to TargetLoweringInfo. This is
needed since the two natural candidates cannot be used:

* The 's' in target data: If this is set to the minimal alignment of any
  argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for
  example.
* The getTransientStackAlignment method. It is possible for an architecture to
  have argument less aligned than what we maintain the stack pointer.

llvm-svn: 108072

llvm-svn: 108071

This assumes that the registers can be copied which is probably a safe
assumption.

llvm-svn: 108070

The remaining copyRegToReg calls actually check the return value (shock!), so we
cannot trivially replace them with COPY instructions.

llvm-svn: 108069

llvm-svn: 108068

llvm-svn: 108067

llvm-svn: 108066

llvm-svn: 108065

'exact' keyword. Thanks to nlewycky for pointing this out!

llvm-svn: 108064

llvm-svn: 108063

llvm-svn: 108062

This also avoids fatal copies from physregs.

llvm-svn: 108061

if a block is split (by a custom inserter), the insert point may be in a
different block than it was originally. This fixes 32-bit llvm-gcc
bootstrap builds, and I haven't been able to reproduce it otherwise.

llvm-svn: 108060

llvm-svn: 108059

operation, but the way it's implemented requires the operation to also be
commutative.  So add a check for commutativity (and tweak the corresponding
comments).  This makes no difference in practice since every associative
LLVM instruction is also commutative!  Here's an example to show the need
for commutativity: the accum_recursion.ll testcase calculates the factorial
function.  Before the transformation the result of a call is
  ((((1*1)*2)*3)...)*x
while afterwards it is
  (((1*x)*(x-1))...*2)*1
which clearly requires both associativity and commutativity of * to be equal
to the original.

llvm-svn: 108056

that loads it, not by linking against them directly.

llvm-svn: 108055