| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 112878
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 112763
|
|
|
|
|
|
| |
infinite loops or exits will eventually exit. This fixes PR5373.
llvm-svn: 112745
|
|
|
|
|
|
| |
if we schedule another LVI-using pass afterwards.
llvm-svn: 112722
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on llvmdev: SRoA is introducing MMX datatypes like <1 x i64>,
which then cause random problems because the X86 backend is
producing mmx stuff without inserting proper emms calls.
In the short term, force off MMX datatypes. In the long term,
the X86 backend should not select generic vector types to MMX
registers. This is being worked on, but won't be done in time
for 2.8. rdar://8380055
llvm-svn: 112696
|
|
|
|
|
|
| |
by 112440 are resolved.
llvm-svn: 112692
|
|
|
|
|
|
|
| |
instead of hoisting them, just fold them away. This occurs in the
testcase for PR8041, for example.
llvm-svn: 112669
|
|
|
|
| |
llvm-svn: 112643
|
|
|
|
|
|
| |
duplicated code into a helper function.
llvm-svn: 112634
|
|
|
|
| |
llvm-svn: 112628
|
|
|
|
| |
llvm-svn: 112625
|
|
|
|
|
|
| |
first failure.
llvm-svn: 112620
|
|
|
|
|
|
|
|
|
| |
two are weak, we make them thunks to a new strong function) so don't iterate
through the function list as we're modifying it.
Also add back the outermost loop which got removed during the cleanups.
llvm-svn: 112595
|
|
|
|
|
|
| |
safely simplify instructions after each block has been processed without worrying about iterator invalidation.
llvm-svn: 112594
|
|
|
|
| |
llvm-svn: 112591
|
|
|
|
| |
llvm-svn: 112590
|
|
|
|
|
|
|
|
|
| |
constant-fold undef, and be more careful with its return value.
This actually exposed an infinite recursion bug in ComputeValueKnownInPredecessors which theoretically already existed (in JumpThreading's
handling of and/or of i1's), but never manifested before. This patch adds a tracking set to prevent this case.
llvm-svn: 112589
|
|
|
|
|
|
|
| |
where we hash, compare and fold, instead of one iteration where we build up
the hash buckets and a second one to fold.
llvm-svn: 112582
|
|
|
|
|
|
|
|
| |
discovered a miscompilation in it, and it's not easily
fixable at the optimizer level. I'll investigate reimplementing it in DAGCombine.
llvm-svn: 112575
|
|
|
|
| |
llvm-svn: 112560
|
|
|
|
| |
llvm-svn: 112553
|
|
|
|
|
|
|
|
| |
constant folding methods. Additionally,
use the ConstantExpr::get*() methods to simplify some constant folding.
llvm-svn: 112550
|
|
|
|
| |
llvm-svn: 112545
|
|
|
|
| |
llvm-svn: 112543
|
|
|
|
|
|
|
|
| |
results from ComputeValueKnownInPredecessors
(indicating undef), and re-use existing constant folding APIs.
llvm-svn: 112539
|
|
|
|
|
|
|
|
| |
instead of PromoteMemToReg. This allows it to stop using DF and DT,
eliminating a computation of DT and DF from clang -O3. Clang is now
down to 2 runs of DomFrontier.
llvm-svn: 112457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assertingvh so we get a violent explosion if the pointer dangles.
2) Fix AliasSetTracker::deleteValue to remove call sites with
by-pointer comparisons instead of by-alias queries. Using
findAliasSetForCallSite can cause alias sets to get merged
when they shouldn't, and can also miss alias sets when the
call is readonly.
#2 fixes PR6889, which only repros with a .c file :(
llvm-svn: 112452
|
|
|
|
|
|
| |
out of loops, just delete them.
llvm-svn: 112451
|
|
|
|
|
|
|
| |
symtab manipulation, so its faster (in addition to being
more elegant)
llvm-svn: 112450
|
|
|
|
| |
llvm-svn: 112449
|
|
|
|
|
|
|
| |
of AST to remove the hoisted instruction from the AST, since it
is no longer in the loop.
llvm-svn: 112448
|
|
|
|
|
|
|
|
|
|
| |
LICM correctly. When sinking an instruction, it should not add
entries for the sunk instruction to the AST, it should remove
the entry for the sunk instruction. The blocks being sunk to
are not in the loop, so their instructions shouldn't be in the
AST (yet)!
llvm-svn: 112447
|
|
|
|
|
|
|
|
|
|
| |
keeping them around until the pass is destroyed, keep them
around a) just when useful (not for outer loops) and b) destroy
them right after we use them. This should reduce memory use
and fixes potential bugs where a loop is deleted and another
loop gets allocated to the same address.
llvm-svn: 112446
|
|
|
|
|
|
| |
claims that it preserves domfrontier if it doesn't really.
llvm-svn: 112445
|
|
|
|
|
|
|
| |
for the unroller to pretend it supports updating it. It still
has a horrible hack for DomTree.
llvm-svn: 112444
|
|
|
|
|
|
|
| |
other filtering techniques, as those may allow it to filter
out more obviously unprofitable candidates.
llvm-svn: 112441
|
|
|
|
|
|
|
|
| |
LSRInstance data structures up to date. This fixes some
pessimizations caused by stale data which will be exposed
in an upcoming change.
llvm-svn: 112440
|
|
|
|
|
|
| |
NarrowSearchSpaceUsingHeuristics into separate functions.
llvm-svn: 112439
|
|
|
|
| |
llvm-svn: 112438
|
|
|
|
| |
llvm-svn: 112437
|
|
|
|
|
|
| |
the high-level logic.
llvm-svn: 112436
|
|
|
|
| |
llvm-svn: 112435
|
|
|
|
| |
llvm-svn: 112434
|
|
|
|
|
|
| |
preserves domfrontier. It does preserve AA though.
llvm-svn: 112419
|
|
|
|
|
|
|
| |
require DomFrontier. Dropping this doesn't actually save any runs
of the pass though.
llvm-svn: 112418
|
|
|
|
|
|
|
| |
Among other things, this uses SSAUpdater instead of
PromoteMemToReg.
llvm-svn: 112417
|
|
|
|
| |
llvm-svn: 112412
|