Synthetic register related: consequences of changing Frame layout.

Synthetic register related: consequences of changing Frame layout.

[Andy Walker]

I am thinking about changing the frame layout for i386, but only when 
Synthetic registers are used.  

In particular, I want to align the hard-frame-pointer on a 32 byte boundary.

My instinct is that I will have to copy the old pc and old frame pointer to 
new locations to correspond to the modified hard-frame-pointer.   I will have 
to hunt down the place that points to the arguments above the 
hard-frame-pointer and adjust them so that the arguments are correctly found.

The saved registers will go below the hard-frame-pointer and the Synthetic 
registers, and I will have to modify the register save/restore processes to 
match the new layout.

What else am I likely to break in the process?

Andy

Re: Synthetic register related: consequences of changing Frame layout.

[Denis Chertykov]

Andy Walker <ja_walker@earthlink.net> writes:

> I am thinking about changing the frame layout for i386, but only when 
> Synthetic registers are used.  
> 
> In particular, I want to align the hard-frame-pointer on a 32 byte boundary.
> 
> My instinct is that I will have to copy the old pc and old frame pointer to 
> new locations to correspond to the modified hard-frame-pointer.   I will have 
> to hunt down the place that points to the arguments above the 
> hard-frame-pointer and adjust them so that the arguments are correctly found.
> 
> The saved registers will go below the hard-frame-pointer and the Synthetic 
> registers, and I will have to modify the register save/restore processes to 
> match the new layout.
> 
> What else am I likely to break in the process?

So, You want to use part of stack frame for Synthetic Registers (SR).

**
I can't found differences between the spilled register (pseudo register
without hard register) and the Synthetic Register.
**

The current allocator trying to find a hard register for any pseudo register
and if this impossible then allocator spill the pseudo to the stack
frame and trying to use the stack slot as register.

The new allocator differs from the current only in allocation methods
not in principles. IE both allocators trying to map infinite number of
pseudo registers to limited set of hard regs, both tring to spill
registers to stack frame and both trying to rematerialize values.

Denis.

Re: Synthetic register related: consequences of changing Frame layout.

[Andy Walker]

On Saturday 04 January 2003 11:52 am, Denis Chertykov wrote:
> Andy Walker <ja_walker@earthlink.net> writes:
> > I am thinking about changing the frame layout for i386, but only when
> > Synthetic registers are used.
> >

<snip>

> >
> > What else am I likely to break in the process?
>
> So, You want to use part of stack frame for Synthetic Registers (SR).
>
> **
> I can't found differences between the spilled register (pseudo register
> without hard register) and the Synthetic Register.
> **

In principle, you are correct.  The differences are small.  I believe that in 
many instances, instructions accessing stack slots as spilled registers are 
six bytes long, not three bytes long as for Synthetic registers.  I believe 
that the compiler does not differentiate between spilled register stack slot 
memory and any other kind of memory, and so generates unnecessary register 
content motion between registers and stack slots, under the mistaken idea 
that this is more efficient.  

I could be completely mistaken.  I will not be sure until I have tried it.

Andy

>
> The current allocator trying to find a hard register for any pseudo
> register and if this impossible then allocator spill the pseudo to the
> stack frame and trying to use the stack slot as register.
>
> The new allocator differs from the current only in allocation methods
> not in principles. IE both allocators trying to map infinite number of
> pseudo registers to limited set of hard regs, both tring to spill
> registers to stack frame and both trying to rematerialize values.
>
> Denis.

Re: Synthetic register related: consequences of changing Frame layout.

[Andy Walker]

On Sunday 05 January 2003 05:40 am, Robert Dewar wrote:
<snip>
> Have you even looked at how code is currently
> generated. 

Yes.

> Registers are spilled to the local stack frame, and of course
> you get the normal 3-byte instructions to transfer to and from the spill
> locations.

With Synthetic registers, you also get a nice set of instructions to handle 
data directly in the Synthetic registers without needing any transfer to a 
natural register -- add, add immediate, xor, neg, rotr, to name a few.  
Another big plus is that Synthetic registers are directly used in 
instructions, instead of requiring a move from a spill location to a natural 
register before being used.

> There is too much general "I believe" guesswork in your approach
> and not enough hard knowledge. 

I can only agree.  

From experience, I hope to gain wisdom.

Andy

Re: Synthetic register related: consequences of changing Frame layout.

[Robert Dewar]

> In principle, you are correct.  The differences are small.  I believe that in 
> many instances, instructions accessing stack slots as spilled registers are 
> six bytes long, not three bytes long as for Synthetic registers.  I believe 
> that the compiler does not differentiate between spilled register stack slot 
> memory and any other kind of memory, and so generates unnecessary register 
> content motion between registers and stack slots, under the mistaken idea 
> that this is more efficient.  

This is completely wrong. Have you even looked at how code is currently
generated. Registers are spilled to the local stack frame, and of course
you get the normal 3-byte instructions to transfer to and from the spill
locations. There is too much general "I believe" guesswork in your approach
and not enough hard knowledge. I suggest that before you start hacking away
at the configuration file, you carefully examine actual generated code at
the machine level (gdb is quite nice for this).