Re: RFA: general prologue analysis framework

[Jim Blandy <jimb@redhat.com>]

Ulrich Weigand <uweigand@de.ibm.com> writes:
>> It looks like your data->gpr_slot[i] array effectively serves the same
>> purpose as an area.  If we had generic code to scan an area and
>> populate a trad_frame_cache, areas might save you code.
>
> Possibly, yes.  I'm not sure I completely understand the pv_area code
> yet -- it appears to be all based on the notion of a fixed base register;
> how to you handle the situation where the base (and/or offset) used to
> access the area change in the middle of the prologue?  Maybe it would
> be better to always base the area on the CFA ...

The comment for make_pv_area was misleading.  Here's a better comment:

    /* Create a new area, tracking stores relative to the original value
       of BASE_REG.  Stores to constant addresses, unknown addresses, or
       to addresses relative to registers other than BASE_REG will trash
       this area; see pv_area_store_would_trash.  */
    struct pv_area *make_pv_area (int base_reg);

So if you pass the SP as the base register, the CFA is exactly what
you get.  The CFA must always be a constant offset from the incoming
value of the SP.  The CFA is constant for a given call, and the
incoming value of the SP is also a constant for a given call, simply
because registers have only one value at a time.  So their difference
must be a constant.