llvm-svn: 36016

some reason.  :(  Will investigate.

llvm-svn: 36011

llvm-svn: 36002

llvm-svn: 35998

llvm-svn: 35996

shouldn't. Also fix some "latent" bug on 64-bit platforms

llvm-svn: 35990

llvm-svn: 35985

printf("") -> noop.  Still need to do the xforms for fprintf.

This implements Transforms/SimplifyLibCalls/Printf.ll

llvm-svn: 35984

in order to clean up after simplifylibcalls.

llvm-svn: 35982

llvm-svn: 35981

llvm-svn: 35979

Writing it twice in the same day was too much for me.

llvm-svn: 35978

llvm-svn: 35977

llvm-svn: 35975

out to do! :)

This fixes a problem where LSR would insert a bunch of code into each MBB
that uses a particular subexpression (e.g. IV+base+C).  The problem is that
this code cannot be CSE'd back together if inserted into different blocks.

This patch changes LSR to attempt to insert a single copy of this code and
share it, allowing codegenprepare to duplicate the code if it can be sunk
into various addressing modes.  On CodeGen/ARM/lsr-code-insertion.ll,
for example, this gives us code like:

        add r8, r0, r5
        str r6, [r8, #+4]
..
        ble LBB1_4      @cond_next
LBB1_3: @cond_true
        str r10, [r8, #+4]
LBB1_4: @cond_next
...
LBB1_5: @cond_true55
        ldr r6, LCPI1_1
        str r6, [r8, #+4]

instead of:

        add r10, r0, r6
        str r8, [r10, #+4]
...
        ble LBB1_4      @cond_next
LBB1_3: @cond_true
        add r8, r0, r6
        str r10, [r8, #+4]
LBB1_4: @cond_next
...
LBB1_5: @cond_true55
        add r8, r0, r6
        ldr r10, LCPI1_1
        str r10, [r8, #+4]

Besides being smaller and more efficient, this makes it immediately
obvious that it is profitable to predicate LBB1_3 now :)

llvm-svn: 35972

this fixes problems where codegenprepare would sink expressions into load/stores
that are not valid, and fixes cases where it would miss important valid ones.

This fixes several serious codesize and perf issues, particularly on targets
with complex addressing modes like arm and x86.  For example, now we compile
CodeGen/X86/isel-sink.ll to:

_test:
        movl 8(%esp), %eax
        movl 4(%esp), %ecx
        cmpl $1233, %eax
        ja LBB1_2       #F
LBB1_1: #T
        movl $4, (%ecx,%eax,4)
        movl $141, %eax
        ret
LBB1_2: #F
        movl (%ecx,%eax,4), %eax
        ret

instead of:

_test:
        movl 8(%esp), %eax
        leal (,%eax,4), %ecx
        addl 4(%esp), %ecx
        cmpl $1233, %eax
        ja LBB1_2       #F
LBB1_1: #T
        movl $4, (%ecx)
        movl $141, %eax
        ret
LBB1_2: #F
        movl (%ecx), %eax
        ret

llvm-svn: 35970

represent a string in binary form by an APInt.

llvm-svn: 35968

llvm-svn: 35967

llvm-svn: 35966

llvm-svn: 35965

llvm-svn: 35963

llvm-svn: 35962

llvm-svn: 35960

less huge code that needs to be cleaned up by sdisel.

llvm-svn: 35959

llvm-svn: 35957

linkage so we only end up with one of them in a program. These are, after
all overloaded and templatish in nature.

llvm-svn: 35956

This can happen for intrinsics that are overloaded.  In such cases it is
necessary to emit a function prototype before the body of the function
that calls the intrinsic and to ensure we don't emit it multiple times.

llvm-svn: 35954

llvm-svn: 35951

llvm-svn: 35950

barf when CBE is run with a program that contains these intrinsics.

llvm-svn: 35946

the size of the value, not just zext. Also, give better names to two BBs.

llvm-svn: 35945

class supports.  In the case of vectors, this means we often get the wrong
type (e.g. we get v4f32 instead of v8i16).  Make sure to convert the vector
result to the right type.  This fixes CodeGen/X86/2007-04-11-InlineAsmVectorResult.ll

llvm-svn: 35944

llvm-svn: 35943

llvm-svn: 35941

llvm-svn: 35940

Implement the "part_set" intrinsic.

llvm-svn: 35938

handlers (like the pass list).  My previous fix only supported *new* command
line options, not additions to old ones.

This fixes test/Feature/load_module.ll

llvm-svn: 35935

llvm-svn: 35926

llvm-svn: 35922

llvm-svn: 35910