Jeff Law wrote:
Ian Lance Taylor wrote:
Jeff Law <l...@redhat.com> writes:
Ian Lance Taylor wrote:
I see no reason for those to stay in reload (especially since I think
reload should disappear entirely). It is reasonable to pick the total
maximum size of the stack frame, and thus resolve all displacement
constraints, before register allocation. Carefully relaxing these
constraints during reload can give you slightly better results for
some
instructions, but only in very very few cases, and only in functions
which already have unusually large stack frames. I don't consider
that
to be an important optimization. Given that, we can determine the
maximum offset for all virtual registers before register allocation,
which suffices for selection of insn constraint alternatives, and then
determine the actual offset, once, after register allocation.
I would agree that careful relaxation of displacements is no longer as
important as it once was, I don't think we can just hand wave away
the displacement issues
1. The stack frames don't have to be that big to bump up against
these problems.
2. The code we generate if we have to reload the address because the
displacement was out of range can be horrific
3. There are targets where other registers used in the insn determine
the range of the displacement. ie, in a load from memory, the
destination register used determines the valid range of displacements
(+-16 bytes vs +-8k on one target I'm aware of.
In all of thse cases, the relaxation loop can only affect a handful of
instructions: the cases where saving a few less registers moves the
offset within range. Those few instructions can only occur in a handful
of functions: the ones where the stack frame is so large that this
becomes an issue at all.
I disagree, particularly because of point #3. I don't see how you
can hand wave it away, that is unless you plan on just making every
load/store of a stack variable/spill be assumed to be out of the +-16
byte range which will generate absolutely horrible code.
On that particular target is isn't uncommon to have situations where
you think you're going to be able to use the +-8k instruction, but
because of spilling you end up using a different register and suddenly
you're stuck with only being able to use +-16 byte offsets.
According my old notes, there are plenty targets with small displacement
issues: avr (0:64), c4x (-255:255), fr30 (-512:512 or 0:64 depending on
data mode), ip2k (0:127), m68c11(0:256), m68k(-128:127), mcore(0:15,
0:30 etc depending on date mode), mmix (0:255), xtensa (0:255 for QI)
and famous sh (0:63). I think not relaxing the displacements will
really hurt the performance especially for targets with small register
file like mcore.
IMHO, another important optimization what reload does for such
processors is usage of already calculated displacement whose value is in
hard register to calculate an new displacement (that was implemented by
Joern for SH).
Although it is hard for me to say how these optimizations will
complicate the new implementation. May be we could sacrifice a small
performance degradation for more clear code. I don't know, only two
tried implementations will show it.
