llvm-svn: 115996

Now that the profitable bits of EnableFullLoadPRE have been enabled by default, rip out the remainder.
Anyone interested in more general PRE would be better served by implementing it separately, to get real
anticipation calculation, etc.

llvm-svn: 115337

We do want to allow LoadPRE to perform LICM-like transformations: we already consider PHI nodes to be negligible for
code size (making this transform code size neutral), and it allows us to hoist values out of loops, which is always
a good thing.

llvm-svn: 115205

LoadPRE was not properly checking that the load it was PRE'ing post-dominated the block it was being hoisted to.
Splitting critical edges at the merge point only addressed part of the issue; it is also possible for non-post-domination
to occur when the path from the load to the merge has branches in it.  Unfortunately, full anticipation analysis is
time-consuming, so for now approximate it.  This is strictly more conservative than real anticipation, so we will miss
some cases that real PRE would allow, but we also no longer insert loads into paths where they didn't exist before. :-)

This is a very slight net positive on SPEC for me (0.5% on average).  Most of the benchmarks are largely unaffected, but
when it pays off it pays off decently: 181.mcf improves by 4.5% on my machine.

llvm-svn: 114785

llvm-svn: 113073

I'm sure it is harmless.  Original commit message:
If PrototypeValue is erased in the middle of using the SSAUpdator
then the SSAUpdator may access freed memory.  Instead, simply pass
in the type and name explicitly, which is all that was used anyway.

llvm-svn: 112810

self host errors on clang-x86-64.

llvm-svn: 112719

then the SSAUpdator may access freed memory.  Instead, simply pass
in the type and name explicitly, which is all that was used anyway.

llvm-svn: 112699

llvm-svn: 112408

llvm-svn: 110489

llvm-svn: 110460

llvm-svn: 110410

ID member as the sole unique type identifier.  Clean up APIs related to this change.

llvm-svn: 110396

llvm-svn: 109103

llvm-svn: 109045

llvm-svn: 107971

llvm-svn: 107969

llvm-svn: 107272

llvm-svn: 106730

llvm-svn: 106729

llvm-svn: 106542

lib/Transforms/Utils and into lib/Analysis so that Analysis passes
can use them.

llvm-svn: 104949

llvm-svn: 103347

This fixes the compile-time regressions seen in last night's tests.

llvm-svn: 103118

indirect branches in all the predecessors.  This avoids unnecessarily
splitting edges in cases where load PRE is not possible anyway.
Thanks to Jakub Staszak for pointing this out.

llvm-svn: 103034

Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.

llvm-svn: 101579

with a fix for self-hosting

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101465

llvm-svn: 101434

with a fix

rotate CallInst operands, i.e. move callee to the back
of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101397

llvm-svn: 101376

llvm-svn: 101368

of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101364

llvm-svn: 100856

llvm-svn: 99488

a loop and is itself the only dependency).

llvm-svn: 97526

predecessors before returning.  Otherwise, if multiple predecessor edges need
splitting, we only get one of them per iteration.  This makes a small but
measurable compile time improvement with -enable-full-load-pre.

llvm-svn: 97521

llvm-svn: 97512

llvm-svn: 97366

argument of createGVNPass and set it automatically for -O3.

llvm-svn: 97245

llvm-svn: 97235