| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 169214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
|
|
|
|
|
|
| |
Scan the body of the loop and find instructions that may trap.
Use this information when deciding if it is safe to hoist or sink instructions.
Notice that we can optimize the search of instructions that may throw in the case of nested loops.
rdar://11518836
llvm-svn: 163132
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This disables malloc-specific optimization when -fno-builtin (or -ffreestanding)
is specified. This has been a problem for a long time but became more severe
with the recent memory builtin improvements.
Since the memory builtin functions are used everywhere, this required passing
TLI in many places. This means that functions that now have an optional TLI
argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead
mallocs anymore if the TLI argument is missing. I've updated most passes to do
the right thing.
Fixes PR13694 and probably others.
llvm-svn: 162841
|
|
|
|
|
|
|
|
|
| |
multiple scalar promotions on a single loop. This also has the effect of
preserving the order of stores sunk out of loops, which is aesthetically
pleasing, and it happens to fix the testcase in PR13542, though it doesn't
fix the underlying problem.
llvm-svn: 161459
|
|
|
|
|
|
| |
has no exit blocks. Fixes PR12706!
llvm-svn: 155884
|
|
|
|
|
|
|
|
|
| |
into Analysis as a standalone function, since there's no need for
it to be in VMCore. Also, update it to use isKnownNonZero and
other goodies available in Analysis, making it more precise,
enabling more aggressive optimization.
llvm-svn: 146610
|
|
|
|
| |
llvm-svn: 145934
|
|
|
|
|
|
| |
Add FIXMEs to places that are non-trivial to fix.
llvm-svn: 145661
|
|
|
|
|
|
| |
yet so it will currently never get used in real tests
llvm-svn: 144107
|
|
|
|
| |
llvm-svn: 138008
|
|
|
|
| |
llvm-svn: 137648
|
|
|
|
|
|
| |
Operations" in LangRef.
llvm-svn: 135625
|
|
|
|
| |
llvm-svn: 134538
|
|
|
|
| |
llvm-svn: 134521
|
|
|
|
|
|
|
|
| |
The promotion code lost any alignment information, when hoisting loads and
stores out of the loop. This lead to incorrect aligned memory accesses. We now
use the largest alignment we can prove to be correct.
llvm-svn: 134520
|
|
|
|
|
|
|
|
| |
says, it's hard to pick good line numbers for this transformation, but something is better than nothing.
rdar://9143729
llvm-svn: 132215
|
|
|
|
|
|
|
|
| |
prevents LICM sinking from erasing debug intrinsics which don't dominate any exit block of the loop.
rdar://9143943 .
llvm-svn: 132201
|
|
|
|
| |
llvm-svn: 132195
|
|
|
|
| |
llvm-svn: 132194
|
|
|
|
| |
llvm-svn: 131956
|
|
|
|
|
|
| |
promoting allocas to SSA variables. Fixes <rdar://problem/9479036>.
llvm-svn: 131953
|
|
|
|
|
|
|
|
|
|
|
| |
is equivalent to any other relevant value; it isn't true in general.
If it is equivalent, the LoopPromoter will tell the AST the equivalence.
Also, delete the PreheaderLoad if it is unused.
Chris, since you were the last one to make major changes here, can you check
that this is sane?
llvm-svn: 129049
|
|
|
|
| |
llvm-svn: 127214
|
|
|
|
|
|
| |
to use it.
llvm-svn: 123501
|
|
|
|
| |
llvm-svn: 122703
|
|
|
|
|
|
|
|
| |
isExitBlockDominatedByBlockInLoop is a relic of the days when domtree was
*just* a tree and didn't have DFS numbers. Checking DFS numbers is faster
and easier than "limiting the search of the tree".
llvm-svn: 122702
|
|
|
|
|
|
| |
which doesn't affect the memory address being promoted.
llvm-svn: 122172
|
|
|
|
|
|
|
| |
does not make the alias set for that pointer volatile, just stores
*to* the pointer.
llvm-svn: 122171
|
|
|
|
|
|
| |
to avoid an unneeded dependence.
llvm-svn: 119557
|
|
|
|
| |
llvm-svn: 118618
|
|
|
|
|
|
| |
uint64_t, plus fixes for places I missed before.
llvm-svn: 116875
|
|
|
|
|
|
|
| |
they do not also require them. This allows us to reduce inter-pass linkage
dependencies.
llvm-svn: 116854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exposes an initializeMyPassFunction(), which
must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
llvm-svn: 116820
|
|
|
|
| |
llvm-svn: 116743
|
|
|
|
|
|
|
|
|
| |
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.
llvm-svn: 116334
|
|
|
|
| |
llvm-svn: 115996
|
|
|
|
|
|
|
|
| |
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: 113146
|
|
|
|
|
|
|
|
|
|
| |
Loop::hasLoopInvariantOperands method. Remove
a useless and confusing Loop::isLoopInvariant(Instruction)
method, which didn't do what you thought it did.
No functionality change.
llvm-svn: 113133
|
|
|
|
|
|
|
|
| |
location is being re-stored to the memory location. We would get
a dangling pointer from the SSAUpdate data structure and miss a
use. This fixes PR8068
llvm-svn: 113042
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
instead of hoisting them, just fold them away. This occurs in the
testcase for PR8041, for example.
llvm-svn: 112669
|
|
|
|
|
|
|
|
| |
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
|