Re: RFA: general prologue analysis framework

Jim Blandy
2005-10-14T18:13:07Z

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.