llvm-svn: 33929

llvm-svn: 33928

llvm-svn: 33927

llvm-svn: 29911

dropped.  This shrinks libllvmgcc.dylib another 67K

llvm-svn: 28975

nondeterminism being bad) could cause some trivial missed optimizations (dead
phi nodes being left around for later passes to clean up).

With this, llvm-gcc4 now bootstraps and correctly compares.  I don't know
why I never tried to do it before... :)

llvm-svn: 27984

has a single def.  In this case, look for uses that are dominated by the def
and attempt to rewrite them to directly use the stored value.

This speeds up mem2reg on these values and reduces the number of phi nodes
inserted.  This should address PR665.

llvm-svn: 24411

llvm-svn: 24410

llvm-svn: 22667

BasicBlock's removePredecessor routine.  This requires shuffling around
the definition and implementation of hasContantValue from Utils.h,cpp into
Instructions.h,cpp

llvm-svn: 22664

llvm-svn: 22523

The optimization for locally used allocas was not safe for allocas that
were read before they were written.  This change disables that optimization
in that case.

llvm-svn: 22318

llvm-svn: 21427

This only fails on darwin or on X86 under valgrind.

llvm-svn: 18377

Patch contributed by Morten Ofstad. Thanks Morten!

llvm-svn: 17123

particular, invoke ret values are only live in the normal dest of the invoke
not in the unwind dest.

llvm-svn: 17108

unneccesary.  This allows us to delete several hundred phi nodes of the
form PHI(x,x,x,undef) from 253.perlbmk and probably other programs as well.

This implements Mem2Reg/UndefValuesMerge.ll

llvm-svn: 17098

llvm-svn: 17045

whose addresses where used by trivial phi nodes and select instructions.  This
is now performed by the instcombine pass, which is more powerful, is much
simpler, and is faster.  This allows the deletion of a bunch of code, two
FIXME's and two gotos.

llvm-svn: 16406

llvm-svn: 16389

llvm-svn: 16347

Patch contributed by Paolo Invernizzi!

llvm-svn: 16152

Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.

llvm-svn: 16137

llvm-svn: 15334

llvm-svn: 14247

non-deterministic things like the ordering of blocks in the dominance
frontier of a BB.  Unfortunately, I don't know of a better way to solve
this problem than to explicitly sort the BB's in function-order before
processing them.  This is guaranteed to slow the pass down a bit, but
is absolutely necessary to get usable diffs between two different tools
executing the mem2reg or scalarrepl pass.

Before this, bazillions of spurious diff failures occurred all over the
place due to the different order of processing PHIs:

-       %tmp.111 = getelementptr %struct.Connector_struct* %upcon.0.0, uint 0, uint 0
+       %tmp.111 = getelementptr %struct.Connector_struct* %upcon.0.1, uint 0, uint 0

Now, the diffs match.

llvm-svn: 14244

llvm-svn: 12779

process them all as a group.  This speeds up SRoA/mem2reg from 28.46s to
0.62s on the testcase from PR209.

llvm-svn: 11100

SRoA/mem2reg from 41.2s to 27.5s on the testcase in PR209.

llvm-svn: 11099

case that the C/C++ front-end generates.

llvm-svn: 10761

llvm-svn: 10727

llvm-svn: 9903

Header files will be on the way.

llvm-svn: 9298

llvm-svn: 9227

"minimal" SSA form (in other words, it doesn't insert dead PHIs).  This
speeds up the mem2reg pass very significantly because it doesn't have to
do a lot of frivolous work in many common cases.

In the 252.eon function I have been playing with, this doesn't even insert
the 120 PHI nodes that it used to which were trivially dead (in the process
of promoting 356 alloca instructions overall).  This speeds up the mem2reg
pass from 1.2459s to 0.1284s.  More significantly, the DCE pass used to take
2.4138s to remove the 120 dead PHI nodes that mem2reg constructed, now it
takes 0.0134s (which is the time to scan the function and decide that there
is nothing dead).  So overall, on this one function, we speed things up a
total of 3.5179s, which is a 24.8x speedup!  :)

This change is tested by the Mem2Reg/2003-10-05-DeadPHIInsertion.ll test,
which now passes.

llvm-svn: 8884

llvm-svn: 8883

basic block.  This is amazingly common in code generated by the C/C++ front-ends.
This change makes it not have to insert ANY phi nodes, whereas before it would insert
a ton of dead ones which DCE would have to clean up.

Thus, this fix improves compile-time performance of these trivial allocas in two ways:
  1. It doesn't have to do the walking and book-keeping for renaming
  2. It does not insert dead phi nodes for them which would have to
     subsequently be cleaned up.

On my favorite testcase from 252.eon, this special case handles 305 out of
356 promoted allocas in the function.  It speeds up the mem2reg pass from 7.5256s
to 1.2505s.  It inserts 677 fewer dead PHI nodes, which speeds up a subsequent
-dce pass from 18.7524s to 2.4806s.

There are still 120 trivially dead PHI nodes being inserted for variables used
in multiple basic blocks, but they are not handled by this patch.

llvm-svn: 8881

llvm-svn: 8865

The VersionNumbers vector is only used during PHI placement.  Turn it into an argument, allowing us to get rid of the vector.

llvm-svn: 8864

*** Revamp the code which handled unreachable code in the function.  Now the
    code is much more efficient for high-degree basic blocks, such as those
    that occur in the 252.eon SPEC benchmark.

For the interested, the time to promote a SINGLE alloca in _ZN7mrScene4ReadERSi
function used to be > 3.5s.  Now it is < .075s.  The function has a LOT of
allocas in it, so it appeared to be infinite looping, this should make it much
nicer.  :)

llvm-svn: 8863