llvm-svn: 41215

details in its own file.

llvm-svn: 41213

llvm-svn: 41202

llvm-svn: 41188

aggregate value and scalar expression computation are very different, this
gets them away from each other.  This causes a temporary regression on some
complex number examples.

llvm-svn: 41014

EmitUsualArithmeticConversions.

llvm-svn: 40931

EmitExprWithUsualUnaryConversions.

llvm-svn: 40929

struct X { int A; };

void foo() {
  struct X s;
  int i;
  i = __builtin_choose_expr(0, s, i);
}

compiles to:

        %tmp = load i32* %i             ; <i32> [#uses=1]
        store i32 %tmp, i32* %i

wow :)

llvm-svn: 40801

llvm-svn: 40788

Rename AddrLabel and OCUVectorComponent -> AddrLabelExpr and OCUVectorElementExpr respectively.  This is for consistency with other expr nodes end with *Expr.

llvm-svn: 40785

    vec2.x = f;

llvm-svn: 40781

llvm-svn: 40780

like this:

typedef __attribute__(( ocu_vector_type(4) )) float float4;
float4 test1(float4 V) {
  return V.wzyx+V;
}

to:
_test1:
        pshufd  $27, %xmm0, %xmm1
        addps   %xmm0, %xmm1
        movaps  %xmm1, %xmm0
        ret

and:

_test1:
        mfspr r2, 256
        oris r3, r2, 4096
        mtspr 256, r3
        li r3, lo16(LCPI1_0)
        lis r4, ha16(LCPI1_0)
        lvx v3, r4, r3
        vperm v3, v2, v2, v3
        vaddfp v2, v3, v2
        mtspr 256, r2
        blr 

llvm-svn: 40771

We can now codegen:

  vec4.xy;

as nothing!

llvm-svn: 40769

llvm-svn: 40162

llvm-svn: 40009

llvm-svn: 39927

llvm-svn: 39831

Both in one patch, and the test case that Chris didn't commit last
time is in there too...

I'll split the patch up if somebody wants it split."

Patch by Keith Bauer.

llvm-svn: 39796

Keith Bauer.

llvm-svn: 39793

llvm-svn: 39765

float4 test(void);
float test2() {
  return test()[1];
}

llvm-svn: 39725

llvm-svn: 39724

llvm-svn: 39718

llvm-svn: 39713

llvm-svn: 39712

llvm-svn: 39711

codegen support for +=.

llvm-svn: 39710

llvm-svn: 39674

of complex.  We now produce optimal code for:

void test(_Complex float *Y) {
  *Y = *Y + *Y;
}

$ clang -emit-llvm cg.c | llvm-as | opt -std-compile-opts | llc -march=x86-64
...
_test:
        movss (%rdi), %xmm0
        addss %xmm0, %xmm0
        movss 4(%rdi), %xmm1
        movss %xmm0, (%rdi)
        addss %xmm1, %xmm1
        movss %xmm1, 4(%rdi)
        ret

llvm-svn: 39673

llvm-svn: 39671

void test(int A, _Complex float Y) {
  _Complex float X;
  X = X;

}

llvm-svn: 39669

One major FIXME though.

llvm-svn: 39666

llvm-svn: 39665

and globals.

llvm-svn: 39661

is ready.

llvm-svn: 39660

out of the llvm namespace.  This makes the clang namespace be a sibling of
llvm instead of being a child.

The good thing about this is that it makes many things unambiguous.  The
bad things is that many things in the llvm namespace (notably data structures
like smallvector) now require an llvm:: qualifier.  IMO, libsystem and libsupport
should be split out of llvm into their own namespace in the future, which will fix
this issue.

llvm-svn: 39659

double foo( int (*FP)(int, int, int)) {
  return FP(1, 2, 3);
}

to:

define double @foo(i32 (i32, i32, i32)* %FP) {
entry:
        %call = tail call i32 %FP( i32 1, i32 2, i32 3 )
        %conv = sitofp i32 %call to double
        ret double %conv
}

llvm-svn: 39658

int test(int X, short Y, float Z) {
  return (int)(X*Y+Z);
}

to:

define i32 @test(i32 %X, i16 %Y, float %Z) {
entry:
        %promote = sext i16 %Y to i32           ; <i32> [#uses=1]
        %mul = mul i32 %promote, %X             ; <i32> [#uses=1]
        %promote3 = sitofp i32 %mul to float            ; <float> [#uses=1]
        %add = add float %promote3, %Z          ; <float> [#uses=1]
        %conv = fptosi float %add to i32                ; <i32> [#uses=1]
        ret i32 %conv
}

with:

$ clang -emit-llvm t.c | llvm-as | opt -std-compile-opts | llvm-dis

llvm-svn: 39652

llvm-svn: 39625