it is both inefficient and unexpected by dwarfdump. Change to
a DW_FORM_data4.
While in here, change the predicate name to reflect that the position
is not really absolute (it is an offset), just that the linker needs a
relocation.
llvm-svn: 130846
but according to my super-optimizer there are only two missed simplifications
of -instsimplify kind when compiling bzip2, and this is one of them. It amuses
me to have bzip2 be perfectly optimized as far as instsimplify goes!
llvm-svn: 130840
This adds functionality to remove size/zero extension during indvars
without generating a canonical IV and rewriting all IV users. It's
disabled by default so should have no effect on codegen. Work in progress.
llvm-svn: 130829
LiveVariables doesn't understand that clobbering D0 and D1 completely overwrites
Q0, so if Q0 is live-in to a function, its live range will extend beyond a
function call that only clobbers D0 and D1. This shows up in the
ARM/2009-11-01-NeonMoves test case.
LiveVariables should probably implement the much stricter rules for physreg
liveness that RAFast imposes - a physreg is killed by the first use of any
alias.
llvm-svn: 130801
Only create a canonical IV for backedge taken count if it will
actually be used by LinearFunctionTestReplace. And some related
cleanup, preparing to reduce dependence on canonical IVs.
No significant effect on x86 or arm in the test-suite.
llvm-svn: 130799
Register coalescing can sometimes create live ranges that end in the middle of a
basic block without any killing instruction. When SplitKit detects this, it will
repair the live range by shrinking it to its uses.
Live range splitting also needs to know about this. When the range shrinks so
much that it becomes allocatable, live range splitting fails because it can't
find a good split point. It is paranoid about making progress, so an allocatable
range is considered an error.
The coalescer should really not be creating these bad live ranges. They appear
when coalescing dead copies.
llvm-svn: 130787
max(a,b) >= a -> true. According to my super-optimizer, these are
by far the most common simplifications (of the -instsimplify kind)
that occur in the testsuite and aren't caught by -std-compile-opts.
llvm-svn: 130780
model constants which can be added to base registers via add-immediate
instructions which don't require an additional register to materialize
the immediate.
llvm-svn: 130743
Def operands may also have an <undef> flag, but that just means that a
sub-register redef doesn't actually read the super-register. For physical
registers, it has no meaning.
llvm-svn: 130714
This works around a limitation in gdb which is reported by following inherit.exp test failures from gdb testsuite.
gdb.cp/inherit.exp: print g_vB.vB::vb
gdb.cp/inherit.exp: print g_vB.vB::vx
gdb.cp/inherit.exp: print g_vC.vC::vc
gdb.cp/inherit.exp: print g_vC.vC::vx
gdb.cp/inherit.exp: print g_vD.vB::vb
...
llvm-svn: 130702
When an interfering live range ends at a dead slot index between two
instructions, make sure that the inserted copy instruction gets a slot index
after the dead ones. This makes it possible to avoid the interference.
Ideally, there shouldn't be interference ending at a deleted instruction, but
physical register coalescing can sometimes do that to sub-registers.
This fixes PR9823.
llvm-svn: 130687
comments claimed it did this, but the LHS value was actually an unused variable.
The new system considers only the '-foo' part when comparing it for typos
against flags that have values, but still look at the whole string for flags
that don't. That way, we'll still correct '-inst=combine' to '-instcombine'.
llvm-svn: 130685
Eli Friedman