| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 106825
|
|
|
|
| |
llvm-svn: 106824
|
|
|
|
| |
llvm-svn: 106728
|
|
|
|
|
|
| |
The ValueMapper used by various cloning utility maps MDNodes also.
llvm-svn: 106706
|
|
|
|
| |
llvm-svn: 106699
|
|
|
|
|
|
| |
Do not use "ValueMap" as a name for a local variable or an argument.
llvm-svn: 106698
|
|
|
|
| |
llvm-svn: 106598
|
|
|
|
|
|
|
|
|
|
|
| |
seeded in value map. This is not limited to function local metadata.
Failure to seed metdata in such cases causes troubles when in a cloned module, metadata from a new module refers to values in old module. Usually this results in mysterious bugpoint crashes. For example,
Checking to see if we can delete global inits: Unknown constant!
UNREACHABLE executed at /d/g/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:904!
llvm-svn: 106592
|
|
|
|
| |
llvm-svn: 106591
|
|
|
|
|
|
| |
Reapply Bob's patch.
llvm-svn: 106560
|
|
|
|
| |
llvm-svn: 106542
|
|
|
|
| |
llvm-svn: 106529
|
|
|
|
|
|
| |
grows.
llvm-svn: 106528
|
|
|
|
|
|
|
| |
--- Reverse-merging r106508 into '.':
U lib/Transforms/Utils/CloneModule.cpp
llvm-svn: 106521
|
|
|
|
| |
llvm-svn: 106508
|
|
|
|
|
|
| |
SmallVector, and other SmallVector simplifications.
llvm-svn: 106452
|
|
|
|
| |
llvm-svn: 106164
|
|
|
|
| |
llvm-svn: 106047
|
|
|
|
|
|
| |
respective store instruction does not have any location info.
llvm-svn: 105490
|
|
|
|
| |
llvm-svn: 105293
|
|
|
|
| |
llvm-svn: 105291
|
|
|
|
|
|
| |
change a few SmallVectors to vanilla C arrays.
llvm-svn: 105289
|
|
|
|
| |
llvm-svn: 105281
|
|
|
|
| |
llvm-svn: 105279
|
|
|
|
|
|
|
| |
the newly created allocas may be used by inlined calls, so these
need to have their tail call flags cleared. Fixes PR7272.
llvm-svn: 105255
|
|
|
|
|
|
| |
first. Fixes PR7265.
llvm-svn: 105206
|
|
|
|
|
|
|
| |
lib/Transforms/Utils and into lib/Analysis so that Analysis passes
can use them.
llvm-svn: 104949
|
|
|
|
| |
llvm-svn: 104914
|
|
|
|
| |
llvm-svn: 104913
|
|
|
|
| |
llvm-svn: 104884
|
|
|
|
| |
llvm-svn: 103457
|
|
|
|
| |
llvm-svn: 103295
|
|
|
|
| |
llvm-svn: 103276
|
|
|
|
|
|
| |
MachineSSAUpdater to avoid duplicating all the code.
llvm-svn: 103060
|
|
|
|
|
|
|
| |
reflect that it includes all inlined calls now, not just
devirtualized ones.
llvm-svn: 102824
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that can have a big effect :). The first is to enable the
iterative SCC passmanager juice that kicks in when the
scc passmgr detects that a function pass has devirtualized
a call. In this case, it will rerun all the passes it
manages on the SCC, up to the iteration count limit (4). This
is useful because a function pass may devirualize a call, and
we want the inliner to inline it, or pruneeh to infer stuff
about it, etc.
The second patch is to add *all* call sites to the
DevirtualizedCalls list the inliner uses. This list is
about to get renamed, but the jist of this is that the
inliner now reconsiders *all* inlined call sites as candidates
for further inlining. The intuition is this that in cases
like this:
f() { g(1); } g(int x) { h(x); }
We analyze this bottom up, and may decide that it isn't
profitable to inline H into G. Next step, we decide that it is
profitable to inline G into F, and do so, which means that F
now calls H. Even though the call from G -> H may not have been
profitable to inline, the call from F -> H may be (in this case
because a constant allows folding etc).
In my spot checks, this doesn't have a big impact on code. For
example, the LLC output for 252.eon grew from 0.02% (from
317252 to 317308) and 176.gcc actually shrunk by .3% (from 1525612
to 1520964 bytes). 252.eon never iterated in the SCC Passmgr,
176.gcc iterated at most 1 time.
llvm-svn: 102823
|
|
|
|
|
|
|
|
|
| |
add a version of createLowerInvokePass that allows the client
to specify whether it wants "expensive" or "cheap" lowering.
Patch by Alex Mac!
llvm-svn: 102402
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where calls inlined into an invoke would get
changed into an invoke but the array would keep pointing to
the (now dead) call. The improved inliner behavior is still
disabled for now.
llvm-svn: 102196
|
|
|
|
|
|
|
|
|
|
| |
that appear in the SCC as a result of inlining as candidates
for inlining. Change this so that it *does* consider call
sites that change from being indirect to being direct as a
result of inlining. This allows it to completely
"devirtualize" the testcase.
llvm-svn: 102146
|
|
|
|
|
|
|
|
| |
arguments are handled with a new InlineFunctionInfo class. This
makes it easier to extend InlineFunction to return more info in the
future.
llvm-svn: 102137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
define void @f3(void (i8*)* %__f) ssp {
entry:
call void %__f(i8* undef)
unreachable
}
define void @f4(i8* %this) ssp align 2 {
entry:
call void @f3(void (i8*)* @f2) ssp
ret void
}
The inliner is turning the indirect call to %__f into a direct
call to F2. Make the call graph more precise when this happens.
The inliner doesn't revisit call sites introduced by inlining,
so there isn't an easy way to test for this, but a more precise
callgraph is a good thing.
llvm-svn: 102131
|
|
|
|
| |
llvm-svn: 102119
|
|
|
|
|
|
| |
GCCAS time for MultiSource/Benchmarks/ASCI_Purple/SMG2000.
llvm-svn: 102009
|
|
|
|
|
|
| |
replationship with ADT/ValueMap.
llvm-svn: 101950
|
|
|
|
| |
llvm-svn: 101949
|
|
|
|
|
|
|
|
|
|
|
| |
to determine where to place PHIs by iteratively comparing reaching definitions
at each block. That was just plain wrong. This version now computes the
dominator tree within the subset of the CFG where PHIs may need to be placed,
and then places the PHIs in the iterated dominance frontier of each definition.
The rest of the patch is mostly the same, with a few more performance
improvements added in.
llvm-svn: 101612
|
|
|
|
|
|
|
| |
Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.
llvm-svn: 101579
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix for self-hosting
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101465
|
|
|
|
| |
llvm-svn: 101434
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a fix
rotate CallInst operands, i.e. move callee to the back
of the operand array
the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary
llvm-svn: 101397
|