Memory operand parsing is a bit haphazzard at the moment, in no small part
due to the even more haphazzard representations of memory operands in the .td
files. Start cleaning that all up, at least a bit.
The addressing modes in the .td files will be being simplified to not be
so monolithic, especially with regards to immediate vs. register offsets
and post-indexed addressing. addrmode3 is on its way with this patch, for
example.
This patch is foundational to enable going back to smaller incremental patches
for the individual memory referencing instructions themselves. It does just
enough to get the basics in place and handle the "make check" regression tests
we already have.
Follow-up work will be fleshing out the details and adding more robust test
cases for the individual instructions, starting with ARM mode and moving from
there into Thumb and Thumb2.
llvm-svn: 136845
LoopPassManager. The incremental update should be extremely cheap in
most cases and can be used in places where it's not feasible to
regenerate the entire loop forest.
- "Unloop" is a node in the loop tree whose last backedge has been removed.
- Perform reverse dataflow on the block inside Unloop to propagate the
nearest loop from the block's successors.
- For reducible CFG, each block in unloop is visited exactly
once. This is because unloop no longer has a backedge and blocks
within subloops don't change parents.
- Immediate subloops are summarized by the nearest loop reachable from
their exits or exits within nested subloops.
- At completion the unloop blocks each have a new parent loop, and
each immediate subloop has a new parent.
llvm-svn: 136844
It is possible to have multiple DBG_VALUEs for the same variable:
32L TEST32rr %vreg0<kill>, %vreg0, %EFLAGS<imp-def>; GR32:%vreg0
DBG_VALUE 2, 0, !"i"
DBG_VALUE %noreg, %0, !"i"
When that happens, keep the last one instead of the first.
llvm-svn: 136842
This helps generate better code in functions with high register
pressure.
The previous version of compact region splitting caused regressions
because the regions were a bit too large. A stronger negative bias
applied in r136832 fixed this problem.
llvm-svn: 136836
Apply twice the negative bias on transparent blocks when computing the
compact regions. This excludes loop backedges from the region when only
one of the loop blocks uses the register.
Previously, we would include the backedge in the region if the loop
preheader and the loop latch both used the register, but the loop header
didn't.
When both the header and latch blocks use the register, we still keep it
live on the backedge.
llvm-svn: 136832
- use SmallVectorImpl& for the function argument.
- ignore the operands on the GEP, even if they aren't constant! Much as we
pretend the malloc succeeds, we pretend that malloc + whatever-you-GEP'd-by
is not null. It's magic!
llvm-svn: 136757
Don't replace a gep/bitcast with 'undef' because that will form a "free(undef)"
which in turn means "unreachable". What we wanted was a no-op. Instead, analyze
the whole tree and look for all the instructions we need to delete first, then
delete them second, not relying on the use_list to stay consistent.
llvm-svn: 136752
This is either an invalid SlotIndex, or valno->def for the first value
defined inside the block. PHI values are not counted as defined inside
the block.
The FirstDef field will be used when estimating the cost of spilling
around a block.
llvm-svn: 136736
The PrefBoth constraint is used for blocks that ideally want a live-in
value both on the stack and in a register. This would be used by a block
that has a use before interference forces a spill.
Secondly, add the ChangesValue flag to BlockConstraint. This tells
SpillPlacement if a live-in value on the stack can be reused as a
live-out stack value for free. If the block redefines the virtual
register, a spill would be required for that.
This extra information will be used by SpillPlacement to more accurately
calculate spill costs when a value can exist both on the stack and in a
register.
The simplest example is a basic block that reads the virtual register,
but doesn't change its value. Spilling around such a block requires a
reload, but no spill in the block.
The spiller already knows this, but the spill placer doesn't. That can
sometimes lead to suboptimal regions.
llvm-svn: 136731