This is the mail archive of the gcc-patches@gcc.gnu.org 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


Ian Lance Taylor wrote:



So you're not really using these for anything, except to give
targetm.reload_icode a way to return a register class.


Yes.

Perhaps we
could simply say that if reload_icode returns a nonnegative number, it
is an instruction code. If reload_icode returns a negative number, it
is - (int) reg_class. (NO_REGS is always 0, and for cases where it
used to return NO_REGS it will now return CODE_FOR_nothing).


Yes, this is certainly a possibility,

Another would be to turn it around and return a positive reg class, or a negative
icode, simple secondary reloads seem to be more common. For this, either the
condition would have to be <= 0, or we'd have to change gensupport.c to initialize
sequence_num to 1.


There is another related issue to consider, however. At the moment we require a
reload pattern to generate tertiary reloads, even if we only need another temporary
register for a straight copy. In principle push_secondary_reload should be able to
handle these without md patterns. If we are given a secondary class that not suitable
for a direct copy from / to the reloaded object, we could find the tertiary class by
calling the secondary reload target hook again, with the secondary class as the reload
class. However, doing this test all the time seems to be unnecessarily costly.
If we have another set of values, one for each reg class, we can use one of these
to indicate that we have a temp register reload that will need a tertiary reload, but no
reload pattern.


Having reserved one set of values in the insn_code enum for reg classes, adding another
set with a slightly different meaning is pretty straightforward; however, when we
first make a decision based on the sign of the returned value, making further distinctions
on other criteria becomes convoluted.



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