On 10/02/2012 06:42 PM, Bernd Schmidt wrote:
On 10/03/2012 12:29 AM, Vladimir Makarov wrote:
On 12-10-02 7:30 AM, Bernd Schmidt wrote:
On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
+ We keep RTL code at most time in such state that the virtual
+ registers can be changed by just the corresponding hard registers
+ (with zero offsets) and we have the right RTL code. To achieve
this
+ we should add initial offset at the beginning of LRA work and update
+ offsets after each stack expanding. But actually we update
virtual
+ registers to the same virtual registers + corresponding offsets
+ before every constraint pass because it affects constraint
+ satisfaction (e.g. an address displacement became too big for some
+ target).
+
+ The final change of virtual registers to the corresponding hard
+ registers are done at the very end of LRA when there were no change
+ in offsets anymore:
+
+ fp + 42 => sp + 42
Let me try to understand this. We have (mem (fp)), which we rewrite to
(mem (fp + 42)), but this is intended to represent (mem (sp + 42))?
Wouldn't this fail on any target which has different addressing ranges
for SP and FP?
Yes, I think so. It is not a problem for 9 current targets. But when I
or somebody else start porting LRA to such target we can introduce new
virtual registers (and switch to them at the begging of LRA) to differ
the situation. It will be not a big deal.
I'd appreciate if you tell me such target in order to know in advance
what to do first when I start work on it.
C6X is such a target. The stack pointer allows a 15 bit unsigned offset,
while all normal registers only allow more limited offsets.
I think the above approach sounds quite hackish and I'd prefer to see
this reworked before merging. Can you retain the current mechanism of
calling eliminate_regs before examining an insn, or is this not workable
for some reason?
I don't think it is worth to rework. That is what I found the best
(and I tried many approaches). Besides it is usefull to see what the
current offsets during debugging just looking on RTL. But the most
important is that it really saves a lot of code, simplifies the
implementation making code much clear.
So that is what I exactly would like to save in this implementation. It
also follows the major design goal to reflect changes in RTL as much as
possible.
