This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Address mode offset spill
- From: Jeff Law <law at redhat dot com>
- To: daniel tian <daniel dot xntian at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 30 Jun 2009 19:45:01 -0600
- Subject: Re: Address mode offset spill
- References: <121fadb80906140733g6b1eec5eg4ea945867f4affb7@mail.gmail.com> <m3y6rt8jne.fsf@google.com> <4A36B7A3.5040403@redhat.com> <m363ex6t9y.fsf@google.com> <4A36C7CA.7070101@redhat.com> <121fadb80906160325q2425b052ib87dadcd66ca6820@mail.gmail.com> <4A43DF1E.80302@redhat.com> <121fadb80906252028s25ac7b7am16d3d0f8490677b9@mail.gmail.com>
daniel tian wrote:
> Only do using R0. Like the following with loading 0x12345:
>
> MOVI 0x2345 -L //To load the lower 16bit data
> MOVI 0x1 -H //Load the up 16bit data
>
OK. So it appears to me like R0 needs to be an intermediate secondary
reload for register anytime you have a load of a large constant integer
into any class other than R0_REGS (I'm assuming you've put R0 into its
own class, which would normally be named R0_REGS).
> Now my approach is to define the Macro PREFERRED_RELOAD_CLASS(X,
> CLASS), and make sure if the X is const int and larger than 512, it
> will return the R0_REG register class.
>
That will certainly help, but won't be sufficient to handle all the
cases. You still need to define your secondary reload class
macros/functions.
> PS: I think that if I don't define the macro LEGITIMIZE_RELOAD_ADDRESS
> which will push reload the larger const int, the
> PREFERRED_RELOAD_CLASS won't be called. is it right?
>
I don't know offhand. If I remember correctly, PREFERRED_RELOAD_CLASS is
another method for optimizing the code -- which means your port should
work with or without PREFERRED_RELOAD_CLASS defined. It also means
there's no guarantee PREFERRED_RELOAD_CLASS will be honored in all cases.
Jeff