This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reload Issue -- I can't believe we haven't hit this before


> Jeffrey A Law wrote:
> ...
> But what worries me even more is spilling.  Say a pseudo has a hard reg
> assigned and is also equivalent to a readonly memory location.  Reload
> then decides to spill the pseudo out of the hard reg because the hard
> reg was needed for something else.  When that occurs we'd have to scan
> affected live range of the pseudo for assignments into the pseudo and
> remove them like I've suggested above.  But that brings another set of
> bookkeeping problems -- we're twiddling reg_equiv_XXX significantly
> later in the reload process, and I'm not sure how safe that's going to
> be.
> 
> Given how rare this situation occurs, I'm leaning towards simply
> ignoring the problematical equivalences.

Wouldn't the following be true for all pseduo's equated to readonly values?:

- if given a hard reg assignment, it may be spilled and reloaded just as any
  value may (thereby the pseudo is now equated with the spilled value), or
  alternatively, it's not literally spilled, it just loses it's hard reg
  assignment, and needs to be regenerated as required, as below):

- if not given a hard reg assignment, but referenced, it's reference is
  equivalent to (mem (symbol ))) with MEM_READONLY_P == true; were if its
  value ends up being stored directly into an allocated hard register, it
  now also has a hard-reg assignment, which is treated as above if the hard
  is reallocated.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]