buildbot: the debugging and non-debugging versions of getFunction were not
functionally equivalent: the non-debugging version wrongly assumed that if a
metadata operand was not metadata, then it had a non-null containing function.
This is not true, since the operand might be a global value, constant etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103008 91177308-0d34-0410-b5e6-96231b3b80d8
RAUW of a global variable with a local variable in function F,
if function local metadata M in function G was using the global
then M would become function-local to both F and G, which is not
allowed. See the testcase for an example. Fixed by detecting
this situation and zapping the metadata operand when it occurs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103007 91177308-0d34-0410-b5e6-96231b3b80d8
in registers into a separate function to de-couple it from the
top-down-specific logic in getRegForValue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102975 91177308-0d34-0410-b5e6-96231b3b80d8
to fadd, fsub, and fmul, when used with a floating-point type. LLVM
has supported the new instructions since 2.6, so it's time to get
on board.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102971 91177308-0d34-0410-b5e6-96231b3b80d8
debug output is showing machine instructions, the IR-level basic block names
aren't very meaningful, and because multiple machine basic blocks may be
derived from one IR-level BB, they're also not unique.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102960 91177308-0d34-0410-b5e6-96231b3b80d8
instructions as the Mac OS X darwin assembler. Some of which like 'fcoml'
assembled to different opcodes. While some of the suffixes were just different.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102958 91177308-0d34-0410-b5e6-96231b3b80d8
caused the a pushl instruction to be incorrectly encoding using only two bytes
of immediate, causing the following 2 instruction bytes to be part of the 32-bit
immediate value. Also fixed the one byte form of push to be used when the
immediate would fit in a signed extended byte. Lastly changed the names to not
include the 32 of PUSH32 since they actually push the size of the stack pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102951 91177308-0d34-0410-b5e6-96231b3b80d8
Also, pass true for isSigned even when creating constants for unsigned
comparisons, because the point is to create an all-ones constant,
rather than UINT64_MAX, even for integers wider than 64 bits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102946 91177308-0d34-0410-b5e6-96231b3b80d8
SimplifyICmpOperands will simplify such cases to EQ or NE. This makes
the correcntess of the code independent on SimplifyICmpOperands doing
certain simplifications.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102927 91177308-0d34-0410-b5e6-96231b3b80d8
beneficial cases. See the changes in test/CodeGen/X86/tail-opts.ll and
test/CodeGen/ARM/ifcvt2.ll for details.
The fix is to change HashEndOfMBB to hash at most one instruction,
instead of trying to apply heuristics about when it will be profitable to
consider more than one instruction. The regular tail-merging heuristics
are already prepared to handle the same cases, and they're more precise.
Also, make test/CodeGen/ARM/ifcvt5.ll and
test/CodeGen/Thumb2/thumb2-branch.ll slightly more complex so that they
continue to test what they're intended to test.
And, this eliminates the problem in
test/CodeGen/Thumb2/2009-10-15-ITBlockBranch.ll, the testcase from
PR5204. Update it accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102907 91177308-0d34-0410-b5e6-96231b3b80d8
preventing the emission of the NOP on Darwin for a
function with no actual code. From timberwolfmc
with TEST=optllcdbg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102843 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102831 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102830 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102823 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102822 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102814 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102798 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102791 91177308-0d34-0410-b5e6-96231b3b80d8
instruction selection is done; it's confusing to see parts of it printed,
while other parts are omitted, along the way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102771 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102770 91177308-0d34-0410-b5e6-96231b3b80d8
MachineFunction::DefaultDebugLoc. We now use the same technique as
DwarfDebug::beginFunction to find the starting line number for a
function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102679 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102672 91177308-0d34-0410-b5e6-96231b3b80d8
level metadata does not have any function local operands.
This would have caught the problem found in PR6112.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102620 91177308-0d34-0410-b5e6-96231b3b80d8
- Also, update dbg_value is the value is being re-matted from a frame slot, e.g. fixed slots for arguments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102565 91177308-0d34-0410-b5e6-96231b3b80d8
alignment of globals to the preferred alignment, but only when
there is no section specified on the global (by far the common
case).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102515 91177308-0d34-0410-b5e6-96231b3b80d8
update them. Computing kill flags is notoriously difficult, and the coalescer
would get it wrong sometimes, and it would completely skip physical registers.
Now we simply remove kill flags based on the live intervals after coalescing.
This is a few percent slower, but now we get correct kill flags for physical
registers after coalescing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102510 91177308-0d34-0410-b5e6-96231b3b80d8
instruction.
This instruction would crash the pass:
INLINEASM <es:foo $0 $1>, 9, %FP0<kill>, 9, %FP0<kill>, 14, %EFLAGS<earlyclobber,def,dead>
Now it doesn't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102509 91177308-0d34-0410-b5e6-96231b3b80d8
- Catch more further dag combine opportunities as result of operand promotion, e.g. (i32 anyext (i16 trunc (i32 x))) -> (i32 x)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102455 91177308-0d34-0410-b5e6-96231b3b80d8
of the dbg testsuite regressions. I don't think this is
really the right fix; this change exposed an existing problem
upstream somewhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102410 91177308-0d34-0410-b5e6-96231b3b80d8
add a version of createLowerInvokePass that allows the client
to specify whether it wants "expensive" or "cheap" lowering.
Patch by Alex Mac!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102402 91177308-0d34-0410-b5e6-96231b3b80d8
otherwise labels get incorrectly merged. We handled this by emitting a
".byte 0", but this isn't correct on thumb/arm targets where the text segment
needs to be a multiple of 2/4 bytes. Handle this by emitting a noop. This
is more gross than it should be because arm/ppc are not fully mc'ized yet.
This fixes rdar://7908505
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102400 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't dominate the header is needed, don't check whether the increment
expression has computable loop evolution. While the operands of an
addrec are required to be loop-invariant, they're not required to
dominate any part of the loop. This fixes PR6914.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102389 91177308-0d34-0410-b5e6-96231b3b80d8
alignment of globals with a specified alignment, we fix
common variables to obey their alignment. Add a comment
explaining why this behavior is important.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102365 91177308-0d34-0410-b5e6-96231b3b80d8
form of DEBUG_VALUE, as it doesn't have reasonable default
behavior for unsupported targets. Add a new hook instead.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102320 91177308-0d34-0410-b5e6-96231b3b80d8
Also, generalize ScalarEvolutions's min and max recognition to handle
some new forms of min and max that this change makes more common.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102234 91177308-0d34-0410-b5e6-96231b3b80d8
refactored out of ScalarEvolution::isImpliedCond, which will be updated
to use this new utility routine soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102229 91177308-0d34-0410-b5e6-96231b3b80d8
alignment to match what's used in clang and GCC for __alignof, rather
than trying to guess what Legalize is going to be doing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102206 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102196 91177308-0d34-0410-b5e6-96231b3b80d8
Add the instruction pointer value for debuggability.
We now get dump output that looks like this:
Call graph node for function: 'f1'<<0x1017086b0>> #uses=1
CS<0x1017046f8> calls external node
Call graph node for function: '_ZNSt6vectorIdSaIdEEC1EmRKdRKS0_'<<0x1017086f0>> #uses=1
CS<0x0> calls external node
Call graph node for function: 'f4'<<0x1017087a0>> #uses=1
CS<0x101708c88> calls function 'f3'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102194 91177308-0d34-0410-b5e6-96231b3b80d8
misses an opportunity to fold add operands, but folds them
after LSR has separated them out. This fixes rdar://7886751.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102157 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102146 91177308-0d34-0410-b5e6-96231b3b80d8
arguments are handled with a new InlineFunctionInfo class. This
makes it easier to extend InlineFunction to return more info in the
future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102137 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102131 91177308-0d34-0410-b5e6-96231b3b80d8
Fix RefreshCallGraph to use CGN->replaceCallEdge instead of hand
rolling its own loop. replaceCallEdge properly maintains the
reference counts of the nodes, fixing a crash exposed by the
iterative callgraph stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102120 91177308-0d34-0410-b5e6-96231b3b80d8
FunctionLoweringInfo, as it isn't SelectionDAG-specific. This isn't
completely natural, as PHI node state is not per-function but rather
per-basic-block, however there's currently no other convenient
per-basic-block state to group it with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102109 91177308-0d34-0410-b5e6-96231b3b80d8
This actually makes everything slower, but the plan is to have isel add <kill>
flags the way it is already adding <dead> flags. Then LiveVariables can be
removed again.
When ignoring the time spent in LiveVariables, -regalloc=fast is now twice as
fast as -regalloc=local.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102034 91177308-0d34-0410-b5e6-96231b3b80d8
