Re: [rfc] Frame based register cache / frame->unwind

[Andrew Cagney <ac131313@cygnus.com>]

> On Apr 14,  4:58pm, Andrew Cagney wrote:
> 
> 
>> I'm not too worried about the apparent 2% overhead per frame create 
>> though.  With the patch applied, the code ends up maintaining both this 
>> new cache and the old ->saved_regs table.  Rewriting a target to just 
>> use the ->unwind_cache, should, I think, claw back the 2% and then some 
>> - less need to go out to the target.
> 
> 
> I'm puzzled.  Assuming you don't have dwarf2cfi or the like, how do you
> avoid maintaining the old ->saved_regs table?

Old code would have ->saved_registers.  Newer code could pre-load the 
cache instead of ->saved_registers.

The case I considered here was SP where ->saved_registers contains the 
value and not the address.  Added the function 
frame_supply_unwound_register() with that in mind.

The others are ``addresses'' though.  The cache would need tinkering for 
this to work - capable of recording the ``address'' and/or the value. 
The frame_supply_unwound_register() (unused) was a step in that direction.


> Hmm...  I see that the unwind cache has an ``addr'' field.  Does that
> mean that that the prologue analysis function calls
> frame_supply_unwound_register() to set this field?

Yes, that is what I had in mind.  But see above, it needs tinkering.

> What is the ``optimized'' flag (in the frame cache) used for?

Grep for OPTIMIZED, it is used but it probably isn't applicable to 
registers.  I just cache everything :-)

There should probably be an ``unavailable'' indication instead, I'm not 
trying to change that part of the code though.  (There is a 
register_valid() call that isn't reliable.)


thanks!
Andrew