Re: Yet another reload_reg_free_for_value_p bug

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.LNX.4.10.9909221354020.9075-100000@biriani.cygnus.co.uk>you 
write:
  > The problem (as far as I can see) is that a single R_F_O_A reload may feed 
  > two different R_O reloads.  There's a bit of code in find_reloads that
  >  merges identical R_F_O_A reloads; look for the comment
  > 
  >   /* See if we have any reloads that are now allowed to be merged
  >      because we've changed when the reload is needed to
  >      RELOAD_FOR_OPERAND_ADDRESS or RELOAD_FOR_OTHER_ADDRESS.  Only
  >      check for the most common cases.  */		 
OK.  

  > So we may end up in a situation where
  >   reload 0: R_F_O_A, opnum 0
  >   reload 1: R_O reload, opnum 0
  >   reload 2: R_O reload, opnum 1
  > 
  > where reloads 0 and 1 conflict due to the fact that reload 0 also feeds
  > reload 2.
But it seems to me that in this case there can be no conflict since we
effectively had two identical R_F_O_A reloads which fed two identical inputs.

So the question remains, can we accurately determine what reloads a R_F_O_A
may conflict with.  And I believe the answer is yes.  You use the same check
that's done in find_reloads (preferably in a subroutine if it can be structured
that way to avoid long term maintenance issues).


  > I've said this before, but I think the current reload_when_needed handling
  > is completely broken - it's incredibly hard to tell which reload types can
  > possibly conflict and which ones can't, and we even cheat in some places to
  > avoid generating some reload types where we know the following code will
  > make incorrect assumptions.
It's certainly poorly designed.  I've argued more than once that someone needs
to clearly document the lifetimes of each and every reload as the first step
to untangling this mess.  Then we proceed to remove the stuff like you've
just found -- preferably by having a single test that can be called from
both functions to avoid version skewing.

jeff