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: Legitimize address after reload

Thanks for you info Julian.

I actually read all the docs and I think I 'more or less' understand
the inner workings of gcc.
What surprises me most is that during the non-strict RTL generation I
do not see any 'strange' address pattern but during the post-reload
process the non-legitimate address comes up. I guess it is due to the
fact that one of the PLUS operands is a memory operand (a local
var.?), thus resulting in double indirect memory address.

In any case I'm not using the restrict variable and I'm assuming
strict is zero, this is, not checking the hard regsiters themselves.
This is because any reg is OK for base reg. I'm pretty sure I'm
behaving similarly to arm, cris or x86 backends.


2014-03-14 13:11 GMT+01:00 Julian Brown <>:
> On Fri, 14 Mar 2014 12:52:35 +0100
> David Guillen <> wrote:
>> If I allow also a 'PLUS' expression to be a valid address (adding the
>> restriction that the two addends are a register and a constant) it
>> happens (sometimes) that gcc comes up with an expression like this
>> one:
>>      (plus:SI (plus:SI (reg:SI somereg)
>>       (const_int 4))
>>      (const_int 8))
>> After taking a look at the 386 backend (and others) I just discovered
>> that there is a function called LEGITIMIZE_RELOAD_ADDRESS which is
>> responsible for handling this case. My issue is that this function is
>> not being called and, from what I saw while debugging, it seems that
>> the offending RTX expression is created after the address_reload pass,
>> and thus impossible for this pass to legitimize the address.
> Look at how e.g. the ARM backend and others handle the "strict"
> parameter to the legitimate_address hook -- you need to use that to
> forbid pseudo registers being allowed in RTXs in the strict case.
> LEGITIMIZE_RELOAD_ADDRESS is probably a red herring (at least for the
> simple cases you're probably dealing with to start with), and isn't used
> for LRA anyway. Getting these bits right can be very fiddly! The (plus
> (reg) (const)) operands can arise before/during during register
> elimination, IIRC. (You might need to get the register-elimination bits
> right, too...)
> Just a guess, anyway. ( might be helpful
> if you've not read it.)
> Julian

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