This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: reload infrastructure to fix PR target/21623
- From: Joern RENNECKE <joern dot rennecke at st dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: Bernd Schmidt <bernds_cb1 at t-online dot de>, gcc-patches at gcc dot gnu dot org, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, aoliva at redhat dot com
- Date: Mon, 03 Oct 2005 15:53:53 +0100
- Subject: Re: RFA: reload infrastructure to fix PR target/21623
- References: <20050927.103622.26298462.kkojima@rr.iij4u.or.jp> <20050927.160054.68062105.kkojima@rr.iij4u.or.jp> <43392D3B.6020905@st.com> <20050927.231900.34738606.kkojima@rr.iij4u.or.jp> <433B0E9A.2000103@st.com> <433CF482.1080201@t-online.de> <433D40E1.5080109@st.com> <433D4227.4090004@st.com> <433D6009.7000002@st.com> <m3mzluxr1w.fsf@gossamer.airs.com> <433DAECA.1010902@st.com> <m364shx6im.fsf@gossamer.airs.com>
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.