This is the mail archive of the
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: <email@example.com> <firstname.lastname@example.org> <4A36B7A3.email@example.com> <firstname.lastname@example.org> <4A36C7CA.email@example.com> <firstname.lastname@example.org> <4A43DF1E.email@example.com> <firstname.lastname@example.org>
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
> 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.