| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
of doing the same thing manually.
llvm-svn: 102997
|
| |
|
|
| |
llvm-svn: 102996
|
| |
|
|
|
|
| |
debug info used by a module.
llvm-svn: 102995
|
| |
|
|
|
|
| |
argument out of the entry block. rdar://7937489
llvm-svn: 102993
|
| |
|
|
|
|
| |
changed to 0x7E from 0x6E as well as the previous change of RPDI to S3SI.
llvm-svn: 102991
|
| |
|
|
|
|
|
|
| |
match failure.
Also, fixes a few memory leak FIXMEs.
llvm-svn: 102986
|
| |
|
|
| |
llvm-svn: 102984
|
| |
|
|
| |
llvm-svn: 102981
|
| |
|
|
|
|
| |
eliminateFrameIndex(), leading to llvm_unreachable() assertion failure.
llvm-svn: 102980
|
| |
|
|
|
|
|
| |
This should make it possible to start producing kill flags in isel without
breaking stuff.
llvm-svn: 102976
|
| |
|
|
|
|
|
| |
in registers into a separate function to de-couple it from the
top-down-specific logic in getRegForValue.
llvm-svn: 102975
|
| |
|
|
|
|
| |
on PPC for x!=0. 7624113.
llvm-svn: 102972
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 102971
|
| |
|
|
|
|
|
|
| |
RemoveCopyByCommutingDef().
This fixes PR6941.
llvm-svn: 102970
|
| |
|
|
| |
llvm-svn: 102966
|
| |
|
|
|
|
| |
same, now that getConstant has overloads consistent with ConstantInt::get.
llvm-svn: 102965
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 102960
|
| |
|
|
| |
llvm-svn: 102959
|
| |
|
|
|
|
|
| |
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.
llvm-svn: 102958
|
| |
|
|
|
|
|
| |
mm to mm/m64 and the Move quadword from xmm2/mem64 to xmm1 had the incorrect
encodings.
llvm-svn: 102952
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 102951
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 102946
|
| |
|
|
| |
llvm-svn: 102941
|
| |
|
|
|
|
| |
Patch by Jakub Staszak!
llvm-svn: 102928
|
| |
|
|
|
|
|
|
| |
SimplifyICmpOperands will simplify such cases to EQ or NE. This makes
the correcntess of the code independent on SimplifyICmpOperands doing
certain simplifications.
llvm-svn: 102927
|
| |
|
|
|
|
|
| |
comparison instructions, since they aren't interesting, despite having
integer result types.
llvm-svn: 102925
|
| |
|
|
|
|
| |
case where both are addrecs in unrelated loops.
llvm-svn: 102924
|
| |
|
|
| |
llvm-svn: 102922
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 102907
|
| |
|
|
| |
llvm-svn: 102906
|
| |
|
|
|
|
|
| |
Remove the -enable-eh option which is only used by the JIT,
and replace it with -jit-enable-eh.
llvm-svn: 102865
|
| |
|
|
| |
llvm-svn: 102852
|
| |
|
|
|
|
|
| |
other places, killing a valid transformation is not the right
answer.
llvm-svn: 102850
|
| |
|
|
|
|
|
|
| |
preventing the emission of the NOP on Darwin for a
function with no actual code. From timberwolfmc
with TEST=optllcdbg.
llvm-svn: 102843
|
| |
|
|
|
|
| |
function as an explicit argument, for use when inlining function pointers.
llvm-svn: 102841
|
| |
|
|
|
|
| |
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
|