Running /Users/void/llvm/llvm.src/test/CodeGen/X86/dg.exp ...
FAIL: /Users/void/llvm/llvm.src/test/CodeGen/X86/2007-11-30-LoadFolding-Bug.ll
Failed with exit(1) at line 1
while running: llvm-as < /Users/void/llvm/llvm.src/test/CodeGen/X86/2007-11-30-LoadFolding-Bug.ll | llc -march=x86 -mattr=+sse2 -stats |&  grep {1 .*folded into instructions}
child process exited abnormally

Make this conditional for now.

llvm-svn: 51563

LBB1_3:   # bb
...
        xorl    %ebp, %ebp
        subl    (%ebx), %ebp
...
        incl    %ecx
        cmpl    %edi, %ecx
        jl      LBB1_3  # bb

Whe using machine LICM, LLVM converts it into:

        xorl %esi, %esi
LBB1_3: # bb
...
        movl    %esi, %ebp
        subl    (%ebx), %ebp
...
        incl    %ecx
        cmpl    %edi, %ecx
        jl      LBB1_3  # bb

Two address conversion inserts the copy instruction. However, it's cheaper to
rematerialize it, and remat helps reduce register pressure.

llvm-svn: 51562

llvm-svn: 51560

Analysis/ConstantFolding to fold ConstantExpr's, then make instcombine use it
to try to use targetdata to fold constant expressions on void instructions.

Also extend the icmp(inttoptr, inttoptr) folding to handle the case where
int size != ptr size.

llvm-svn: 51559

Patch by Mikael Lepistö.

llvm-svn: 51540

llvm-svn: 51538

This fixes PR2359

llvm-svn: 51536

llvm-svn: 51535

llvm-svn: 51533

Eliminate x86.sse2.movs.d, x86.sse2.shuf.pd, x86.sse2.unpckh.pd, and x86.sse2.unpckl.pd intrinsics. These will be lowered into shuffles.

llvm-svn: 51531

so that gcc doesn't warn about them.

llvm-svn: 51529

sections on ppc32 darwin.  g++.dg/abi/key2.C

llvm-svn: 51527

llvm-svn: 51526

llvm-svn: 51523

Remove x86.sse2.loadh.pd and x86.sse2.loadl.pd. These will be lowered into load and shuffle instructions.

llvm-svn: 51522

Remove x86.sse2.loadh.pd and x86.sse2.loadl.pd. These will be lowered into load and shuffle instructions.

llvm-svn: 51521

llvm-svn: 51513

llvm-svn: 51505

llvm-svn: 51503

llvm-svn: 51501

use it instead of duplicating its functionality.

llvm-svn: 51499

llvm-svn: 51496

llvm-svn: 51493

llvm-svn: 51491

llvm-svn: 51490

load-folding table entries for PMULDQ and PMULLD.

llvm-svn: 51489

llvm-svn: 51487

elements that have been erased.  Based on a patch
by Nicolas Capens.

llvm-svn: 51485

This fixes recent CBE regressions.

llvm-svn: 51483

llvm-svn: 51482

The SimplifyCFG pass looks at basic blocks that contain only phi nodes,
followed by an unconditional branch. In a lot of cases, such a block (BB) can
be merged into their successor (Succ).

This merging is performed by TryToSimplifyUncondBranchFromEmptyBlock. It does
this by taking all phi nodes in the succesor block Succ and expanding them to
include the predecessors of BB. Furthermore, any phi nodes in BB are moved to
Succ and expanded to include the predecessors of Succ as well.

Before attempting this merge, CanPropagatePredecessorsForPHIs checks to see if
all phi nodes can be properly merged. All functional changes are made to
this function, only comments were updated in
TryToSimplifyUncondBranchFromEmptyBlock.

In the original code, CanPropagatePredecessorsForPHIs looks quite convoluted
and more like stack of checks added to handle different kinds of situations
than a comprehensive check. In particular the first check in the function did
some value checking for the case that BB and Succ have a common predecessor,
while the last check in the function simply rejected all cases where BB and
Succ have a common predecessor. The first check was still useful in the case
that BB did not contain any phi nodes at all, though, so it was not completely
useless.

Now, CanPropagatePredecessorsForPHIs is restructured to to look a lot more
similar to the code that actually performs the merge. Both functions now look
at the same phi nodes in about the same order.  Any conflicts (phi nodes with
different values for the same source) that could arise from merging or moving
phi nodes are detected. If no conflicts are found, the merge can happen.

Apart from only restructuring the checks, two main changes in functionality
happened.

Firstly, the old code rejected blocks with common predecessors in most cases.
The new code performs some extra checks so common predecessors can be handled
in a lot of cases. Wherever common predecessors still pose problems, the
blocks are left untouched.

Secondly, the old code rejected the merge when values (phi nodes) from BB were
used in any other place than Succ. However, it does not seem that there is any
situation that would require this check. Even more, this can be proven.

Consider that BB is a block containing of a single phi node "%a" and a branch
to Succ. Now, since the definition of %a will dominate all of its uses, BB
will dominate all blocks that use %a. Furthermore, since the branch from BB to
Succ is unconditional, Succ will also dominate all uses of %a.

Now, assume that one predecessor of Succ is not dominated by BB (and thus not
dominated by Succ). Since at least one use of %a (but in reality all of them)
is reachable from Succ, you could end up at a use of %a without passing
through it's definition in BB (by coming from X through Succ). This is a
contradiction, meaning that our original assumption is wrong. Thus, all
predecessors of Succ must also be dominated by BB (and thus also by Succ).

This means that moving the phi node %a from BB to Succ does not pose any
problems when the two blocks are merged, and any use checks are not needed.

llvm-svn: 51478

llvm-svn: 51477

llvm-svn: 51476

llvm-svn: 51475

llvm-svn: 51474

instruction for doing this?

llvm-svn: 51473

llvm-svn: 51472

llvm-svn: 51471

and/or to handle more cases (such as this add-sitofp.ll testcase), and
port it to selectiondag's ComputeNumSignBits.

llvm-svn: 51469

and bitcode support for the extractvalue and insertvalue
instructions and constant expressions.

Note that this does not yet include CodeGen support.

llvm-svn: 51468