does normal initialization and normal chaining. Change the default
AliasAnalysis implementation to NoAlias.

Update StandardCompileOpts.h and friends to explicitly request
BasicAliasAnalysis.

Update tests to explicitly request -basicaa.

llvm-svn: 116720

forwarding is implemented with a load/store pair rather than a memcpy.

llvm-svn: 116637

llvm-svn: 116462

llvm-svn: 116461

logic to use the new APInt methods.  Among other things this
implements rdar://8501501 - llvm.smul.with.overflow.i32 should constant fold

which comes from "clang -ftrapv", originally brought to my attention from PR8221.

llvm-svn: 116457

Now using a variant of the existing inlining heuristics to decide whether to create a given specialization of a function in PartialSpecialization.  If the total performance bonus across all callsites passing the same constant exceeds the specialization cost, we create the specialization.

llvm-svn: 116158

llvm-svn: 116004

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

llvm-svn: 115296

llvm-svn: 115295

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

llvm-svn: 115116

llvm-svn: 115111

llvm-svn: 115095

llvm-svn: 115091

Fix PR8247: JumpThreading can cause a block to become unreachable while still having predecessor, if it is part of a self-loop.
Because of this, we cannot use the Simplify* APIs, as they can assert-fail on unreachable code.  Since it's not easy to determine
if a given threading will cause a block to become unreachable, simply defer simplifying simplification to later InstCombine and/or
DCE passes.

llvm-svn: 115082

Usually we wouldn't do this anyway because llvm_fenv_testexcept would return an
exception, but we have seen some cases where neither errno nor fenv detect an
exception on arm-linux.

llvm-svn: 114893

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

Be more precise when trying to XFAIL this tester: http://google1.osuosl.org:8011/builders/llvm-arm-linux

llvm-svn: 114755

llvm-svn: 114241

llvm-svn: 114202

"inexact" result.

llvm-svn: 114198

so that it detects errors on platforms where libm doesn't set errno.
It's still subject to host libm details though.

llvm-svn: 114148

llvm-svn: 114106

It is possible, under specific circumstances involving ptrtoint ConstantExpr's, for LVI to end up trying to merge
a Constant into a ConstantRange.  Handle this conservatively for now, rather than asserting.  The testcase is
more complex that I would like, but the manifestation of the problem is sensitive to iteration orders and the state of the
LVI cache, and I have not been able to reproduce it with manually constructed or simplified cases.

Fixes PR8162.

llvm-svn: 114103

to replace an instruction with itself.  Add a predicate to the simplifier to prevent this case.

llvm-svn: 114097

attribute(used).

llvm-svn: 113911

llvm-svn: 113855

deleted.  Fix this by doing the copyValue's before we delete stuff!

The testcase only repros the problem on my system with valgrind.

llvm-svn: 113820

llvm-svn: 113770

to expose greater opportunities for store narrowing in codegen.  This patch fixes a potential
infinite loop in instcombine caused by one of the introduced transforms being overly aggressive.

llvm-svn: 113763

on to Owen.

llvm-svn: 113720

This can result in increased opportunities for store narrowing in code generation.  Update a number of
tests for this change.  This fixes <rdar://problem/8285027>.

Additionally, because this inverts the order of ors and ands, some patterns for optimizing or-of-and-of-or
no longer fire in instances where they did originally.  Add a simple transform which recaptures most of these
opportunities: if we have an or-of-constant-or and have failed to fold away the inner or, commute the order 
of the two ors, to give the non-constant or a chance for simplification instead.

llvm-svn: 113679

Reassociate does this but it doesn't catch all cases (e.g. if the operands are i1).

llvm-svn: 113651

Revert r113439, which relaxed the requirement that loops containing calls cannot be unrolled.  After some discussion,
there seems to be a better way to achieve the same effect.

llvm-svn: 113528

Relax the "don't unroll loops containing calls" rule.  Instead, when a loop contains a call, lower the
unrolling threshold to the optimize-for-size threshold.  Basically, for loops containing calls, unrolling
can still be profitable as long as the loop is REALLY small.

llvm-svn: 113439

Generalize instcombine's support for combining multiple bit checks into a single test.  Patch by Dirk Steinke!

llvm-svn: 113423

turning (fptrunc (sqrt (fpext x))) -> (sqrtf x)  is great, but we have
to delete the original sqrt as well.  Not doing so causes us to do 
two sqrt's when building with -fmath-errno (the default on linux).

llvm-svn: 113260

llvm-svn: 113257

llvm-svn: 113146