calculated.

llvm-svn: 122912

llvm-svn: 122911

llvm-svn: 122909

in the predecessor block, leading to an incorrect conclusion for the edge value.  Found by inspection.

llvm-svn: 122908

My i386 llvm-gcc nightly tester found a regression for
SingleSource/Benchmarks/McGill/chomp that a bisect blamed on 122743.
That seems strange but apparently the combination of earlycse and instcombine
did something bad.  Chris says he intended to remove the instcombine pass, so
let's go ahead and try that.  We'll see if there are any performance losses.

llvm-svn: 122907

hasBlockValue() that was causing iterator invalidations.  Many thanks to Dimitry Andric for
tracking down those invalidations!

llvm-svn: 122906

llvm-svn: 122893

llvm-svn: 122891

Commit 122778 broke DWARF debug output when using the MBlaze backend. Fixed by overriding TargetFrameInfo::getFrameIndexOffset to take into account the new frame index information.

llvm-svn: 122889

regressing code quality.

llvm-svn: 122887

llvm-svn: 122886

llvm-svn: 122885

llvm-svn: 122884

llvm-svn: 122883

llvm-svn: 122882

llvm-svn: 122881

entities easier.

llvm-svn: 122880

llvm-svn: 122879

llvm-svn: 122876

Fix lit for people whose LLVM path contains 'opt', which is a common directory name on Unix-like systems.

llvm-svn: 122873

step is to only process instructions in subloops if they have been modified by
an earlier simplification.

llvm-svn: 122869

skipping them, but it should probably use a worklist and only revisit those
instructions in subloops that have actually changed. It should probably also
use a worklist after the first iteration like instsimplify now does. Regardless,
it's only 0.3% of opt -O2 time on 403.gcc if it replaces the instcombine placed
in the middle of the loop passes.

llvm-svn: 122868

It forms memset and memcpy's, and will someday form popcount and
other stuff.  All of this is bad when compiling the implementation
of memset, memcpy, popcount, etc.

llvm-svn: 122854

llvm-svn: 122849

Don't bother value numbering instructions with void types in GVN. In theory this should allow us to insert
fewer things into the value numbering maps, but any speedup is beneath the noise threshold on my machine
on 403.gcc.

llvm-svn: 122844

bundles in the pass.

llvm-svn: 122833

The analysis will be needed by both the greedy register allocator and the
X86FloatingPoint pass. It only needs to be computed once when the CFG doesn't
change.

This pass is very fast, usually showing up as 0.0% wall time.

llvm-svn: 122832

warning is overzealous but gcc is what it is.)

llvm-svn: 122829

llvm-svn: 122828

llvm-svn: 122827

llvm-svn: 122826

Clarify terminology, settling on referring to what was the "number table" as the "leader table", and
rename methods to make it much more clear what they're doing.

llvm-svn: 122823

llvm-svn: 122822

case where a static caller is itself inlined everywhere else, and
thus may go away if it doesn't get too big due to inlining other
things into it.  If there are references to the caller other than
calls, it will not be removed; account for this.
This results in same-day completion of the case in PR8853.

llvm-svn: 122821

Branch instructions don't produce values, so there's no need to generate a value number for them.  This
avoids adding them to the various value numbering tables, resulting in a minor (~3%) speedup for GVN
on 40.gcc.

llvm-svn: 122819

llvm-svn: 122817

llvm-svn: 122816

llvm-svn: 122815

ashr's with huge shift amounts, PR8896

llvm-svn: 122814

llvm-svn: 122812