| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
when needed. This fixes PR7001
llvm-svn: 102838
|
| |
|
|
| |
llvm-svn: 102836
|
| |
|
|
| |
llvm-svn: 102835
|
| |
|
|
|
|
| |
This should fix PR6603.
llvm-svn: 102834
|
| |
|
|
|
|
|
|
|
|
| |
halting analysis, it is illegal to delete a call to a read-only function.
The correct solution is almost certainly to add a "must halt" attribute and
only allow deletions in its presence.
XFAIL the relevant testcase for now.
llvm-svn: 102831
|
| |
|
|
|
|
|
| |
if an indirect call site was removed and a direct one was added, not
just if an indirect call site was modified to be direct.
llvm-svn: 102830
|
| |
|
|
|
|
|
| |
handles argument lowering anyway, so there's no need for special
casing here.
llvm-svn: 102828
|
| |
|
|
| |
llvm-svn: 102827
|
| |
|
|
| |
llvm-svn: 102826
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that appear due to inlining a callee as candidates for
futher inlining, but a recent patch made it do this if
those call sites were indirect and became direct.
Unfortunately, in bizarre cases (see testcase) doing this
can cause us to infinitely inline mutually recursive
functions into callers not in the cycle. Fix this by
keeping track of the inline history from which callsite
inline candidates got inlined from.
This shouldn't affect any "real world" code, but is required
for a follow on patch that is coming up next.
llvm-svn: 102822
|
| |
|
|
|
|
| |
try to put a kill flag on a DBG_INFO instruction.
llvm-svn: 102820
|
| |
|
|
|
|
|
| |
Seen in SingleSrc/Benchmarks/Misc/flops with TEST=optllcdbg.
7929951.
llvm-svn: 102819
|
| |
|
|
| |
llvm-svn: 102817
|
| |
|
|
|
|
| |
modified.
llvm-svn: 102816
|
| |
|
|
|
|
|
|
|
|
|
| |
code, and to eliminate the need for the SelectionDAGBuilder
state to be live during CodeGenAndEmitDAG calls.
Call SDB->clear() before CodeGenAndEmitDAG calls instead of
before it, and move the CurDAG->clear() out of SelectionDAGBuilder,
which doesn't own the DAG, and into CodeGenAndEmitDAG.
llvm-svn: 102814
|
| |
|
|
| |
llvm-svn: 102810
|
| |
|
|
|
|
| |
changes before doing phi lowering for switches.
llvm-svn: 102809
|
| |
|
|
| |
llvm-svn: 102799
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
were still inlining self-recursive functions into other functions.
Inlining a recursive function into itself has the potential to
reduce recursion depth by a factor of 2, inlining a recursive
function into something else reduces recursion depth by exactly
1. Since inlining a recursive function into something else is a
weird form of loop peeling, turn this off.
The deleted testcase was added by Dale in r62107, since then
we're leaning towards not inlining recursive stuff ever. In any
case, if we like inlining recursive stuff, it should be done
within the recursive function itself to get the algorithm
recursion depth win.
llvm-svn: 102798
|
| |
|
|
|
|
|
|
| |
indexes could be of a different value type. Or not even using the same SDNode
for the constant (weird, I know). Compare the actual values instead of the
pointers.
llvm-svn: 102791
|
| |
|
|
|
|
|
| |
instruction selection is done; it's confusing to see parts of it printed,
while other parts are omitted, along the way.
llvm-svn: 102771
|
| |
|
|
|
|
|
|
|
|
| |
call that might throw. The landing pad assumes that all registers are in stack
slots.
We used to spill those dirty CSRs after the call, and the stack slots would be
wrong when arriving at the landing pad.
llvm-svn: 102770
|
| |
|
|
|
|
|
|
| |
argument.
Radar 7927803
llvm-svn: 102760
|
| |
|
|
|
|
|
| |
on the original variables, so it's easier to see what is being done
to which blocks.
llvm-svn: 102759
|
| |
|
|
| |
llvm-svn: 102743
|
| |
|
|
| |
llvm-svn: 102742
|
| |
|
|
|
|
|
| |
for unsigned purposes, so >64-bit integer values get a full all-ones
value.
llvm-svn: 102739
|
| |
|
|
| |
llvm-svn: 102734
|
| |
|
|
| |
llvm-svn: 102733
|
| |
|
|
| |
llvm-svn: 102730
|
| |
|
|
|
|
| |
Rounding differences causes tests to fail on Linux.
llvm-svn: 102729
|
| |
|
|
|
|
|
| |
comparisons sign-extended to a different bitwidth than the
comparison operands.
llvm-svn: 102721
|
| |
|
|
|
|
| |
it's only safe to do a tail call if the results are returned in the same way.
llvm-svn: 102683
|
| |
|
|
| |
llvm-svn: 102680
|
| |
|
|
|
|
|
|
| |
MachineFunction::DefaultDebugLoc. We now use the same technique as
DwarfDebug::beginFunction to find the starting line number for a
function.
llvm-svn: 102679
|
| |
|
|
|
|
| |
easy cases.
llvm-svn: 102678
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
of different register classes. e.g.
%reg1048:3<def> = EXTRACT_SUBREG %RAX<kill>, 3
Where %reg1048 is a GR32 register. This is not impossible to handle, but it is
pretty hard and very rare.
This should unbreak the dragonegg builder.
llvm-svn: 102672
|
| |
|
|
|
|
| |
print randomly in debug output.
llvm-svn: 102668
|
| |
|
|
| |
llvm-svn: 102666
|
| |
|
|
| |
llvm-svn: 102663
|
| |
|
|
| |
llvm-svn: 102661
|
| |
|
|
| |
llvm-svn: 102657
|
| |
|
|
|
|
|
|
|
|
| |
##DEBUG_VALUE: runOnMachineFunction:this <- RDI+0
##DEBUG_VALUE: runOnMachineFunction:fn <- RSI+0
##DEBUG_VALUE: DeadDefs <- undef ## SimpleRegisterCoalescing.cpp:2706
##DEBUG_VALUE: getRegInfo:this <- [%rsp+$56]+$0
##DEBUG_VALUE: getTarget:this <- [%rsp+$56]+$0
llvm-svn: 102655
|
| |
|
|
| |
llvm-svn: 102654
|
| |
|
|
|
|
| |
entry block.
llvm-svn: 102653
|
| |
|
|
|
|
|
| |
level metadata does not have any function local operands.
This would have caught the problem found in PR6112.
llvm-svn: 102620
|
| |
|
|
| |
llvm-svn: 102606
|
| |
|
|
| |
llvm-svn: 102602
|