X = sext x; x >s c ? X : C+1 --> X = sext x; X <s C+1 ? C+1 : X
X = sext x; x <s c ? X : C-1 --> X = sext x; X >s C-1 ? C-1 : X
X = zext x; x >u c ? X : C+1 --> X = zext x; X <u C+1 ? C+1 : X
X = zext x; x <u c ? X : C-1 --> X = zext x; X >u C-1 ? C-1 : X
X = sext x; x >u c ? X : C+1 --> X = sext x; X <u C+1 ? C+1 : X
X = sext x; x <u c ? X : C-1 --> X = sext x; X >u C-1 ? C-1 : X

Instead of calculating this with mixed types promote all to the
larger type. This enables scalar evolution to analyze this
expression. PR8866

llvm-svn: 123034

llvm-svn: 123033

llvm-svn: 123030

llvm-svn: 123025

This happens when we take the (non-constant) length from a malloc.

llvm-svn: 122961

InstCombine: If we call llvm.objectsize on a malloc call we can replace it with the size passed to malloc.

llvm-svn: 122959

llvm-svn: 122958

OptimizeInst() so that they can be used on a worklist instruction.

llvm-svn: 122945

llvm-svn: 122944

into a separate function, so that it can be called from a loop using a worklist
rather than a loop traversing a whole basic block.

llvm-svn: 122943

Simplify RALinScan::DowngradeRegister with TRI::getOverlaps while we are there.

llvm-svn: 122940

worklist, the key will need to become std::pair<BasicBlock*, Value*>.

llvm-svn: 122932

llvm-svn: 122891

regressing code quality.

llvm-svn: 122887

llvm-svn: 122876

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

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

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: 122815

when safe.

The testcase is basically this nested loop:
void foo(char *X) {
  for (int i = 0; i != 100; ++i) 
    for (int j = 0; j != 100; ++j)
      X[j+i*100] = 0;
}

which gets turned into a single memset now.  clang -O3 doesn't optimize
this yet though due to a phase ordering issue I haven't analyzed yet.

llvm-svn: 122806

instruction *after* the store.  The store will always be deleted
if the transformation kicks in, so we'd do an N^2 scan of every
loop block.  Whoops.

llvm-svn: 122805

CodeGenPrepare (which is the default behavior).

llvm-svn: 122801

FunctionPass. It probably doesn't have a reason to be a LoopPass, as it will
probably drop the simple fixed point and either use RPO iteration or Duncan's
approach in instsimplify of only revisiting instructions that have changed.

The next step is to preserve LoopSimplify. This looks like it won't be too hard,
although the pass manager doesn't actually seem to respect when non-loop passes
claim to preserve LCSSA or LoopSimplify. This will have to be fixed.

llvm-svn: 122791

stop setting NSW: signed overflow is possible.  Thanks to Dan
for pointing these out.

llvm-svn: 122790

llvm-svn: 122788

Use the new addEscapingValue callback to update GlobalsModRef when GVN adds PHIs of GEPs. For the moment,
have GlobalsModRef handle this conservatively by simply removing the value from its maps.

llvm-svn: 122787

invalidated by stores, so they can be handled as 'simple'
operations.

llvm-svn: 122785

almost-but-not-quite-identical code.  No intended functionality change.

llvm-svn: 122760

that are allowed to have metadata operands are intrinsic calls,
and the only ones that take metadata currently return void.
Just reject all void instructions, which should not be value
numbered anyway.  To future proof things, add an assert to the
getHashValue impl for calls to check that metadata operands 
aren't present.

llvm-svn: 122759

nested values, so they can change and drop to null, which can
change the hash and cause havok.

It turns out that it isn't a good idea to value number stuff
with metadata operands anyway, so... don't.

llvm-svn: 122758

InstructionSimplify on instructions that didn't change since the
last time round the loop.

llvm-svn: 122745

capacity on the Visited SmallPtrSet. On 403.gcc, this is about a 4.5% speedup of
CodeGenPrepare time (which itself is 10% of time spent in the backend).

This is progress towards PR8889.

llvm-svn: 122741