It's not safe to tell SplitCriticalEdge to merge identical edges. It may delete the phi instruction that's being processed.

llvm-svn: 43524

- Allow icmp rewrite using an iv / stride of a smaller integer type.

llvm-svn: 43480

llvm-svn: 43463

llvm-svn: 43462

llvm-svn: 43461

llvm-svn: 43460

- ChangeCompareStride only reuse stride that is larger than current stride. It
  will let the general reuse mechanism to try to reuse a smaller stride.
- Watch out for multiplication overflow in ChangeCompareStride.
- Replace std::set with SmallPtrSet.

llvm-svn: 43408

llvm-svn: 43384

Loosen up iv reuse to allow reuse of the same stride but a larger type when truncating from the larger type to smaller type is free.
e.g.
Turns this loop:
LBB1_1: # entry.bb_crit_edge
        xorl    %ecx, %ecx
        xorw    %dx, %dx
        movw    %dx, %si
LBB1_2: # bb
        movl    L_X$non_lazy_ptr, %edi
        movw    %si, (%edi)
        movl    L_Y$non_lazy_ptr, %edi
        movw    %dx, (%edi)
		addw    $4, %dx
		incw    %si
		incl    %ecx
		cmpl    %eax, %ecx
		jne     LBB1_2  # bb
	
into

LBB1_1: # entry.bb_crit_edge
        xorl    %ecx, %ecx
        xorw    %dx, %dx
LBB1_2: # bb
        movl    L_X$non_lazy_ptr, %esi
        movw    %cx, (%esi)
        movl    L_Y$non_lazy_ptr, %esi
        movw    %dx, (%esi)
        addw    $4, %dx
		incl    %ecx
        cmpl    %eax, %ecx
        jne     LBB1_2  # bb

llvm-svn: 43375

stride may be rewritten using the stride of the compare instruction.

llvm-svn: 43367

llvm-svn: 43356

and the compaison is against a constant value, try eliminate the stride
by moving the compare instruction to another stride and change its
constant operand accordingly. e.g.

loop:
...
v1 = v1 + 3
v2 = v2 + 1
if (v2 < 10) goto loop
=>
loop:
...
v1 = v1 + 3
if (v1 < 30) goto loop

llvm-svn: 43336

 - Avoid attempting stride-reuse in the case that there are users that
   aren't addresses. In that case, there will be places where the
   multiplications won't be folded away, so it's better to try to
   strength-reduce them.

 - Several SSE intrinsics have operands that strength-reduction can
   treat as addresses. The previous item makes this more visible, as
   any non-address use of an IV can inhibit stride-reuse.

 - Make ValidStride aware of whether there's likely to be a base
   register in the address computation. This prevents it from thinking
   that things like stride 9 are valid on x86 when the base register is
   already occupied.

Also, XFAIL the 2007-08-10-LEA16Use32.ll test; the new logic to avoid
stride-reuse elimintes the LEA in the loop, so the test is no longer
testing what it was intended to test.

llvm-svn: 43231

SCEV subclasses to being non-static member functions of the ScalarEvolution
class.

llvm-svn: 43224

llvm-svn: 42508

gvn, gvnpre, dse, and predsimplify.  To see these, use:

  make check-line-length

llvm-svn: 40738

llvm-svn: 40673

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