Re: RFC: reloading sums

[Michael Matz <matz at suse dot de>]

Hi,

On Fri, 20 Jun 2003, Joern Rennecke wrote:

> If you want to write, test and debug such a patch for 3.5, that would be
> kind of neat, but I won't hold my breath.

;-)

> In the meantime, we have a a bug to fix, and disabling an optimization
> under circumstances when we are almost certain the optimization would be
> incorrect is a save way to do it.

Of course, but I felt this was just papering over the problem instead of
fixing it.  I thought so, because as far as reload knows this optimization
_is_ valid, if it weren't for the broken gen_reload() function.  Because
of this I'm not sure if your patch really fixes the problem.  It disables
the optimization that r13 is chosen as reload reg early.  But noone says
that nothing else will also chose r13 later.  It could do so, because of
the reload type, because r13 is dead after the insn, and no other reload
is needing r13.

> The sh addsi3 expander does not accept this constant when compiling for
> -m5-compact.  The constant load is generated by gen_reload.

Ah.  You mean the case which has the comment
      ??? At some point, this whole thing needs to be rethought.  */
? ;-)

I now see that here the cleverness of gen_reload (namely that it tries to
handle difficult cases) interacts poorly with push_reload.  But I feel
more that this is a bug gen_reload.

Hmm, I think if you already determined, that this particular reload can
not be done in a single insn by gen_reload() it should also be promoted to
RELOAD_OTHER to ensure that really noone selects its input registers as
reload regs (except if that is already ensured by some other means?)

> > Not necessarily.  The real condition is "if the add can be done without
> > clobbering it's inputs".  Well, such an add should be producable anyway.
>
> How would you produce such an add?

With a "(clobber scratch)"  ;-)  I know, this won't help you.  It a
problem of ill-defined requirements of gen_reload.


Ciao,
Michael.