This is the mail archive of the 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: RFA: reload infrastructure to fix PR target/21623

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.

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