Reload bug causing x86 problems

[Jeffrey A Law]

  In message < 199905270017.BAA18675@phal.cygnus.co.uk >you write:
  > As long as the merged reloads are actually done, everything is fine: the
  > address reloads have the replacements inside the reload_in expressions,
  > thus we'll end up loading the reload_in expression with the remaining
  > replacements into the reload register, and the reload register replaces
  > the two different reload_in-s.
  > 
  > 
  > The problem is really that the merged reload is optional, and not done 
  > after all.
OK.  I think I understand.

When we merge reloads in this manner, what are the rules which determine
if the resulting merged reload is optional?

If both are optional, then the result is optional.

If both are mandatory, then the result is mandatory.

But what about the case where they are mixed (ie, one mandatory and
one optional).  What is the result in this case?  Don't we need to
set/clear reload_optional[i] to match the resulting reload in this
case?


  > - disable the call to remove_address_replacements if both merged
  >   reloads are optional (because that means that the merged one
  >   will be optional too).
Certainly possible.  I did a hack similar to this locally as part of
some testing.  Though mine disabled the call to remove_address_replacements
anytime the lower numbered reload was marked as optional.

  > So I think you should go with the first way and make a comment why the
  > second one is wrong.
Sounds good once we determine what (if anything) we need to do for the 
case where one is optional and the other mandatory.

  > Looking at remove_address_replacements, I wonder if we can also end up
  > using a single register for an address that is used in another reload
  > as part of a group?
I can't see a reason why we would not run into this case.  Unless you're
talking about reloads within a single insn.

jeff