llvm-svn: 42960

a problem when asserts are on).  From vecLib.

llvm-svn: 42959

long double.

llvm-svn: 42958

- Added Sema::AddFactoryMethodToGlobalPool and Sema::AddInstanceMethodToGlobalPool and DenseMaps. This will allow us to efficiently lookup a method from a selector given no type information (for the "id" data type).

- Fixed some funky "}
                    else {" indentation in Sema::ActOnAddMethodsToObjcDecl(). I'd prefer we stay away from this style...it wastes space and isn't any easier to read (from my perspective, at least:-)

- Changed Parser::ParseObjCInterfaceDeclList() to only call Action::ActOnAddMethodsToObjcDecl() when it actually has methods to add (since most interface have methods, this is a very minor cleanup).

llvm-svn: 42957

llvm-svn: 42956

trampolines, rather than with nested functions themselves.

llvm-svn: 42955

values and propagate demanded bits through them in simple cases.

This allows this code:
void foo(char *P) {
   strcpy(P, "abc");
}
to compile to:

_foo:
        ldrb r3, [r1]
        ldrb r2, [r1, #+1]
        ldrb r12, [r1, #+2]!
        ldrb r1, [r1, #+1]
        strb r1, [r0, #+3]
        strb r2, [r0, #+1]
        strb r12, [r0, #+2]
        strb r3, [r0]
        bx lr

instead of:

_foo:
        ldrb r3, [r1, #+3]
        ldrb r2, [r1, #+2]
        orr r3, r2, r3, lsl #8
        ldrb r2, [r1, #+1]
        ldrb r1, [r1]
        orr r2, r1, r2, lsl #8
        orr r3, r2, r3, lsl #16
        strb r3, [r0]
        mov r2, r3, lsr #24
        strb r2, [r0, #+3]
        mov r2, r3, lsr #16
        strb r2, [r0, #+2]
        mov r3, r3, lsr #8
        strb r3, [r0, #+1]
        bx lr

testcase here: test/CodeGen/ARM/truncstore-dag-combine.ll

This also helps occasionally for X86 and other cases not involving 
unaligned load/stores.

llvm-svn: 42954

llvm-svn: 42953

truncate and truncstore instructions, based on the 
knowledge that they don't demand the top bits.

llvm-svn: 42952

llvm-svn: 42951

If the power of 5 is exact, and the reciprocal exact, the error is zero not one half-ulps.  This prevents an infinite loop in rare cases.

llvm-svn: 42950

llvm-svn: 42949

llvm-svn: 42948

Turn this:
movswl  %ax, %eax
movl    %eax, -36(%ebp)
xorl    %edi, -36(%ebp)
into
movswl  %ax, %eax
xorl    %edi, %eax
movl    %eax, -36(%ebp)
by unfolding the load / store xorl into an xorl and a store when we know the
value in the spill slot is available in a register. This doesn't change the
number of instructions but reduce the number of times memory is accessed.

Also unfold some load folding instructions and reuse the value when similar
situation presents itself.

llvm-svn: 42947

register used by the unfolded instructions. User can also specify whether to
unfold the load, the store, or both.

llvm-svn: 42946

llvm-svn: 42945

$ clang rewrite.c -rewrite-test
prints:

int foo() {
        b:      foo();
f:      foo();
    foo();
}

for:

int foo() {
	b:	foo();
f:	foo();
    foo();
}

amazing.

llvm-svn: 42944

llvm-svn: 42943

llvm-svn: 42942

insert stuff.

llvm-svn: 42941

some incredibly subtle details that I'm working on getting
right.

llvm-svn: 42940

llvm-svn: 42939

llvm-svn: 42938

llvm-svn: 42937

llvm-svn: 42936

llvm-svn: 42935

for fastcc from X86CallingConv.td.  This means that nested functions
are not supported for calling convention 'fastcc'.

llvm-svn: 42934

printf format strings.  Added type checking to see if the matching
width/precision argument was of type 'int'.

Thanks to Anders Carlsson for reporting this missing feature.

llvm-svn: 42933

that includes the string "st". This probably fixes the regression on
Darwin.

llvm-svn: 42932

llvm-svn: 42931

Do not filter memmove.

llvm-svn: 42930

llvm-svn: 42929

llvm-svn: 42928

Thanks to Török Edvin for helping to track this down.

llvm-svn: 42927

ok class names and streamlined this logic to do the lookup once.

llvm-svn: 42926

longer be created for fastcc functions.

llvm-svn: 42925

llvm-svn: 42924

Replace one FIXME with another. We handle protocols just fine now. The ObjC decl will only be 0 when we have an error on the ObjC decl. I would prefer we pass in a decl that is marked as invalid. I don't think this is critical to fix now, however I'd like us to be consistent. There are currently many places that don't mark the decl as invalid (which need to be fixed)...

llvm-svn: 42923

llvm-svn: 42922

llvm-svn: 42921