| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Thanks Duncan for the idea
llvm-svn: 159687
|
|
|
|
|
|
| |
Unfortunately this change requires the cache map to hold WeakVHs instead
llvm-svn: 159667
|
|
|
|
|
|
|
|
| |
ValueHandle keys.
No functionality change.
llvm-svn: 159497
|
|
|
|
|
|
| |
recognize invoke, and shouldnt at this point, since the rest of LLVM codebase doesnt expect invoke of intrinsics
llvm-svn: 159441
|
|
|
|
| |
llvm-svn: 159417
|
|
|
|
|
|
|
| |
(a.k.a. MDNodes). The module doesn't belong in Analysis. Move it to the VMCore
instead.
llvm-svn: 159414
|
|
|
|
|
|
| |
the assert reported in PR13228!
llvm-svn: 159393
|
|
|
|
|
|
|
|
| |
- recognize C++ new(std::nothrow) friends
- ignore ExtractElement and ExtractValue instructions in size/offset analysis (all easy cases are probably folded away before we get here)
- also recognize realloc as noalias
llvm-svn: 159356
|
|
|
|
|
|
| |
that in the default branch the value cannot be any of the switch cases)
llvm-svn: 159353
|
|
|
|
|
|
| |
the range of the block. Previously it was only performing the intersection for a few cases, thus losing precision
llvm-svn: 159320
|
|
|
|
| |
llvm-svn: 159314
|
|
|
|
|
|
|
|
|
| |
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.
The reasoning is because the DebugInfo module is simply an interface to the
debug info MDNodes and has nothing to do with analysis.
llvm-svn: 159312
|
|
|
|
| |
llvm-svn: 159239
|
|
|
|
|
|
|
|
|
| |
It's not necessary for each DI class to have its own copy of `print' and
`dump'. Instead, just give DIDescriptor those methods and have it call the
appropriate debugging printing routine based on the type of the debug
information.
llvm-svn: 159237
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The primary advantage is that loop optimizations will be applied in a
stable order. This helps debugging and unit test creation. It is also
a better overall implementation without pathologically bad performance
on deep functions.
On large functions (llvm-stress --size=200000 | opt -loops)
Before: 0.1263s
After: 0.0225s
On deep functions (after tweaking llvm-stress, thanks Nadav):
Before: 0.2281s
After: 0.0227s
See r158790 for more comments.
The loop tree is now consistently generated in forward order, but loop
passes are applied in reverse order over the program. If we have a
loop optimization that prefers forward order, that can easily be
achieved by adding a different type of LoopPassManager.
llvm-svn: 159183
|
|
|
|
| |
llvm-svn: 159182
|
|
|
|
| |
llvm-svn: 159145
|
|
|
|
| |
llvm-svn: 159112
|
|
|
|
| |
llvm-svn: 158999
|
|
|
|
|
|
| |
user. Update GlobalOpt accordingly.
llvm-svn: 158952
|
|
|
|
|
|
|
|
| |
Update comments accordingly.
Make instcombine remove useless invokes to C++'s 'new' allocation function (test attached).
llvm-svn: 158937
|
|
|
|
|
|
| |
Thanks to Chandler for pointing out the problem.
llvm-svn: 158928
|
|
|
|
|
|
| |
and were crashing this code on 64 bits machines
llvm-svn: 158923
|
|
|
|
|
|
|
|
|
|
|
|
| |
- provide more extensive set of functions to detect library allocation functions (e.g., malloc, calloc, strdup, etc)
- provide an API to compute the size and offset of an object pointed by
Move a few clients (GVN, AA, instcombine, ...) to the new API.
This implementation is a lot more aggressive than each of the custom implementations being replaced.
Patch reviewed by Nick Lewycky and Chandler Carruth, thanks.
llvm-svn: 158919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-stable-loops enables a new algorithm for generating the Loop
forest. It differs from the original algorithm in a few respects:
- Not determined by use-list order.
- Initially guarantees RPO order of block and subloops.
- Linear in the number of CFG edges.
- Nonrecursive.
I didn't want to change the LoopInfo API yet, so the block lists are
still inclusive. This seems strange to me, and it means that building
LoopInfo is not strictly linear, but it may not be a problem in
practice. At least the block lists start out in RPO order now. In the
future we may add an attribute or wrapper analysis that allows other
passes to assume RPO order.
The primary motivation of this work was not to optimize LoopInfo, but
to allow reproducing performance issues by decomposing the compilation
stages. I'm often unable to do this with the current LoopInfo, because
the loop tree order determines Loop pass order. Serializing the IR
tends to invert the order, which reverses the optimization order. This
makes it nearly impossible to debug interdependent loop optimizations
such as LSR.
I also believe this will provide more stable performance results across time.
llvm-svn: 158790
|
|
|
|
|
|
|
|
|
| |
The implementation only needs inclusion from LoopInfo.cpp and
MachineLoopInfo.cpp. Clients of the interface should only include the
interface. This makes the interface readable and speeds up rebuilds
after modifying the implementation.
llvm-svn: 158787
|
|
|
|
|
|
|
|
| |
LLVM is now -Wunused-private-field clean except for
- lib/MC/MCDisassembler/Disassembler.h. Not sure why it keeps all those unaccessible fields.
- gtest.
llvm-svn: 158096
|
|
|
|
| |
llvm-svn: 157885
|
|
|
|
|
|
| |
Part of rdar://11570854
llvm-svn: 157786
|
|
|
|
| |
llvm-svn: 157704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also required making recursive simplifications until
nothing changes or a hard limit (currently 3) is hit.
With the simplification in place indvars can canonicalize
loops of the form
for (unsigned i = 0; i < a-b; ++i)
into
for (unsigned i = 0; i != a-b; ++i)
which used to fail because SCEV created a weird umax expr
for the backedge taken count.
llvm-svn: 157701
|
|
|
|
|
|
|
|
|
| |
If integer overflow causes one of the terms to reach zero, that can
force the entire expression to zero.
Fixes PR12929: cast<Ty>() argument of incompatible type
llvm-svn: 157673
|
|
|
|
|
|
| |
No functionality.
llvm-svn: 157672
|
|
|
|
| |
llvm-svn: 157377
|
|
|
|
|
|
| |
Part of rdar://11496790
llvm-svn: 157303
|
|
|
|
|
|
| |
Fixes PR12898: SCEVExpander crash.
llvm-svn: 157263
|
|
|
|
|
|
|
|
| |
to generate out of the front end.
rdar://11479676
llvm-svn: 157094
|
|
|
|
|
|
|
|
|
|
| |
getUDivExpr attempts to simplify by checking for overflow.
isLoopEntryGuardedByCond then evaluates the loop predicate which
may lead to the same getUDivExpr causing endless recursion.
Fixes PR12868: clang 3.2 segmentation fault.
llvm-svn: 157092
|
|
|
|
|
|
| |
same switch instruction by doing union of ranges (which may still be conservative, but it's more aggressive than before)
llvm-svn: 157071
|
|
|
|
| |
llvm-svn: 157033
|
|
|
|
| |
llvm-svn: 157024
|
|
|
|
| |
llvm-svn: 157011
|
|
|
|
|
|
|
|
| |
getZeroExtendExpr()
this gives a speedup of > 80 in a debug build in the test case of PR12825 (php_sha512_crypt_r)
llvm-svn: 156849
|
|
|
|
|
|
| |
getEffectiveSCEVType() twice
llvm-svn: 156823
|
|
|
|
|
|
|
|
|
| |
so that it can be reused in MemCpyOptimizer. This analysis is needed to remove
an unnecessary memcpy when returning a struct into a local variable.
rdar://11341081
PR12686
llvm-svn: 156776
|
|
|
|
|
|
| |
intended.
llvm-svn: 156687
|
|
|
|
| |
llvm-svn: 156589
|
|
|
|
| |
llvm-svn: 156558
|
|
|
|
|
|
| |
of recursion, to avoid excessive stack usage on deep expressions.
llvm-svn: 156554
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add a new Region::block_iterator which actually iterates over the basic
blocks of the region.
The old iterator, now call 'block_node_iterator' iterates over
RegionNodes which contain a single basic block. This works well with the
GraphTraits-based iterator design, however most users actually want an
iterator over the BasicBlocks inside these RegionNodes. Now the
'block_iterator' is a wrapper which exposes exactly this interface.
Internally it uses the block_node_iterator to walk all nodes which are
single basic blocks, but transparently unwraps the basic block to make
user code simpler.
While this patch is a bit of a wash, most of the updates are to internal
users, not external users of the RegionInfo. I have an accompanying
patch to Polly that is a strict simplification of every user of this
interface, and I'm working on a pass that also wants the same simplified
interface.
This patch alone should have no functional impact.
llvm-svn: 156202
|