Re: RFA: reload infrastructure to fix PR target/21623

[Joern RENNECKE <joern dot rennecke at st dot com>]

Bernd Schmidt wrote:

>  
> I haven't looked closely at your patch yet, but one idea I had once 
> was to just return an icode from SECONDARY_*_RELOAD_CLASS as well, 
> losing the reload_{in,out} optabs entirely.  Would that work?

It would allow equal or more functionality than my patch to add more 
specific reload expanders.
It wouldn't allow backwards compatibility, however, unless you want to 
have the new macro or
hook live alongside the existing SECONDARY*_RELOAD_CLASS macros, and 
reload_{in,out}
optabs for unconverted ports.
We could have multiple clobbers which are found by looking at the actual 
instruction; however,
we should probably require that the patterns has a standard form, i.e. 
operands 0 and 1 being input
and output, respectively, all scratch clobbers using match_opeand, and 
clobbers of fixed registers
not using match_operand.
We could allow both inputs and outputs to be non-matching, with the 
result of using temporary
registers there.  However, if these moves need scratch registers, or we 
need more than three
steps, we need push_secondary_reload to recurse to handle these moves.
We could also dispense with SECONDARY_MEM_NEEDED by using patterns
with a MEM on one side.  Like for non-matching register classes, 
push_secondary_reload
would be expected to generate one or more reloads to make assiciated 
operand reach the MEM.
The dependncy information for copies is readyly available from the way 
the reloads feed each
other.  However, if constants need to be loaded, or special values 
calculated from the inputs -
other than by find_reloads_address - that would remain unknown to 
reload, it would only know
about scratch register usage for these, so there would be no cse 
opportunities for these.