directly, because the insert point used by the SCEVExpander may vary
from what LSR originally computes.

llvm-svn: 40641

deleteValueFromRecords and loosen the types to all it to accept
Value* instead of just Instruction*, since this is what
ScalarEvolution uses internally anyway. This allows more flexibility
for future uses.

llvm-svn: 37657

This created an ambiguity for expandInTy to decide when to use
sign-extension or zero-extension, but it turns out that most of its callers
don't actually need a type conversion, now that LLVM types don't have
explicit signedness. Drop expandInTy in favor of plain expand, and change
the few places that actually need a type conversion to do it themselves.

llvm-svn: 37591

llvm-svn: 37499

llvm-svn: 37454

into:

_t:
        movl 8(%esp), %ecx
        movl 4(%esp), %eax
        cmpl %ecx, %eax
        je LBB1_3       #bb17
LBB1_1: #bb
        cmpl %ecx, %eax
        jg LBB1_4       #cond_true
LBB1_2: #cond_false
        subl %eax, %ecx
        cmpl %ecx, %eax
        jne LBB1_1      #bb
LBB1_3: #bb17
        ret
LBB1_4: #cond_true
        subl %ecx, %eax
        cmpl %ecx, %eax
        jne LBB1_1      #bb
        jmp LBB1_3      #bb17

instead of:

_t:
        subl $4, %esp
        movl %esi, (%esp)
        movl 12(%esp), %ecx
        movl 8(%esp), %eax
        cmpl %ecx, %eax
        je LBB1_4       #bb17
LBB1_1: #bb.outer
        movl %ecx, %edx
        negl %edx
LBB1_2: #bb
        cmpl %ecx, %eax
        jle LBB1_5      #cond_false
LBB1_3: #cond_true
        addl %edx, %eax
        cmpl %ecx, %eax
        jne LBB1_2      #bb
LBB1_4: #bb17
        movl (%esp), %esi
        addl $4, %esp
        ret
LBB1_5: #cond_false
        movl %ecx, %edx
        subl %eax, %edx
        movl %eax, %esi
        addl %esi, %esi
        cmpl %ecx, %esi
        je LBB1_4       #bb17
LBB1_6: #cond_false.bb.outer_crit_edge
        movl %edx, %ecx
        jmp LBB1_1      #bb.outer

llvm-svn: 37252

llvm-svn: 36996

slightly nicer than using CallInst with an extra check; thanks Chris.

llvm-svn: 36743

address operand in a prefetch intrinsic.

llvm-svn: 36713

llvm-svn: 36662

Due to darwin gcc bug, one version of darwin linker coalesces
static const int, which defauts PassID based pass identification.

llvm-svn: 36652

llvm-svn: 36632

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070423/048333.html

llvm-svn: 36380

Remove ImmediateDominator analysis.  The same information can be obtained from DomTree.  A lot of code for
constructing ImmediateDominator is now folded into DomTree construction.

This is part of the ongoing work for PR217.

llvm-svn: 36063

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

llvm-svn: 35837

llvm-svn: 35731

llvm-svn: 35615

llvm-svn: 35607

target hook.  This allows us to codegen a loop as:

LBB1_1: @cond_next
        mov r2, #0
        str r2, [r0, +r3, lsl #2]
        add r3, r3, #1
        cmn r3, #1
        bne LBB1_1      @cond_next

instead of:

LBB1_1: @cond_next
        mov r2, #0
        str r2, [r0], #+4
        add r3, r3, #1
        cmn r3, #1
        bne LBB1_1      @cond_next

This looks the same, but has one fewer induction variable (and therefore,
one fewer register) live in the loop.

llvm-svn: 35592

llvm-svn: 35563

llvm-svn: 35347

instructions (that would have to be split later)

llvm-svn: 35227

llvm-svn: 35224

llvm-svn: 35197

llvm-svn: 35086

llvm-svn: 35072

User from the list of I users.

llvm-svn: 35051

llvm-svn: 34984

Replace expensive getZExtValue() == 0 calls with isZero() calls.

llvm-svn: 34861

llvm-svn: 34860

llvm-svn: 34859

llvm-svn: 34822

Constant::isNullValue() in situations where it is possible.

llvm-svn: 34821

llvm-svn: 34156

the Transforms library. This reduces debug library size by 132 KB, debug
binary size by 376 KB, and reduces link time for llvm tools slightly.

llvm-svn: 33939

rename Type::getIntegralTypeMask to Type::getIntegerTypeMask.

This makes naming much more consistent.  For example, there are now no longer any
instances of IntegerType that are not considered isInteger! :)

llvm-svn: 33225

llvm-svn: 33218

Enable complex addressing modes on 64-bit platforms involving two induction
variables by keeping a size and scale in 64-bits not 32.
Patch by Dan Gohman.

llvm-svn: 33011

llvm-svn: 32946