llvm-svn: 24705

llvm-svn: 24704

llvm-svn: 24703

llvm-svn: 24702

void %foo(<4 x float> * %a) {
entry:
  %tmp1 = load <4 x float> * %a;
  %tmp2 = mul <4 x float> %tmp1, %tmp1
  store <4 x float> %tmp2, <4 x float> *%a
  ret void
}

Is selected to:

_foo:
        li r2, 0
        lvx v0, r2, r3
        vxor v1, v1, v1
        vmaddfp v0, v0, v0, v1
        stvx v0, r2, r3
        blr

llvm-svn: 24701

llvm-svn: 24700

the module being constructed. This is used to correctly name the module.
Previously the name of the linker tool was used which produces confusing
output when the module identifier is used in an error message.

llvm-svn: 24699

a) use better local variable names (OldMT -> OldFT) where "M" is used to
   mean "Function" (perhaps it was previously "Method"?)
b) print out the module identifier in a warning message so that it is
   possible to track down in which module the error occurred.

llvm-svn: 24698

llvm-svn: 24697

llvm-svn: 24696

llvm-svn: 24695

for emitting the ctor/dtor list for common targets.

llvm-svn: 24694

llvm-svn: 24693

llvm-svn: 24692

ConstantVec legalizing code, which would return constantpool nodes that
were not of the target's pointer type.

llvm-svn: 24691

llvm-svn: 24690

llvm-svn: 24689

A few helper fragments for loads. e.g. (i8 (load addr:$src)) -> (loadi8 addr:$src). Only to improve readibility.

llvm-svn: 24688

llvm-svn: 24687

llvm-svn: 24686

llvm-svn: 24685

llvm-svn: 24684

llvm-svn: 24683

  This enables the removal of some explicit type casts.
* Rename immZExt8 to i16ZExt8 as well.

llvm-svn: 24682

llvm-svn: 24681

llvm-svn: 24680

  if (!N.Val->hasOneUse()) {
    std::map<SDOperand, SDOperand>::iterator CGMI = CodeGenMap.find(N);
    if (CGMI != CodeGenMap.end()) return CGMI->second;
  }

Suppose a DAG like this:

           X
         ^   ^
        /     \
      USE1    USE2

Suppose USE1 is being selected first and during which X is selected and
returned a new node. After this, USE1 is no longer an use of X. During USE2
selection, X will be selected again since it has only one use!

The fix is to always query CodeGenMap.

llvm-svn: 24679

llvm-svn: 24678

llvm-svn: 24677

llvm-svn: 24676

llvm-svn: 24675

base or index operands being selected.

llvm-svn: 24674

first before the chain.
e.g.
int X;

int foo(int x)
{
  x += X + 37;
  return x;
}

If chain operand is selected first, we would generate:
	movl X, %eax
	movl 4(%esp), %ecx
	leal 37(%ecx,%eax), %eax

rather than
	movl $37, %eax
	addl 4(%esp), %eax
	addl X, %eax

which does not require %ecx. (Due to ADD32rm not matching.)

llvm-svn: 24673

llvm-svn: 24672

llvm-svn: 24671

llvm-svn: 24670

Bug fix: finding the correct incoming chain for pattern with nested src operand. And a minor change to make output code slightly more readible.

llvm-svn: 24669

llvm-svn: 24668

186.crafty by about 16% (from 15.109s to 13.045s) on my system.

This turns allocas with unions/casts into scalars.  For example crafty has
something like this:

    union doub {
      unsigned short i[4];
      long long d;
    };
int f(long long a) {
  return ((union doub){.d=a}).i[1];
}

Instead of generating loads and stores to an alloca, we now promote the
whole thing to a scalar long value.

This implements: Transforms/ScalarRepl/AggregatePromote.ll

llvm-svn: 24667

the presense of pointer casts

llvm-svn: 24666