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

On 03/14/14 05:52, David Guillen wrote:

I'm writing a simple gcc backend and I'm experiencing a weird thing
regarding address legitimation process. Two scenarios:

If I only allow addresses to be either a register or symbols my gcc
works. To do so I add the restrictions into the
TARGET_LEGITIMATE_ADDRESS_P macro. This makes gcc to force registers
for all the addresses.

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

      (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.

Looking at other architectures it seems that they are doing more or
less the same, so I don't know what the issue might be.
LEGITIMIZE_RELOAD_ADDRESS is a hook that allows the target to rewrite invalid addresses during the reload pass in such a way that reload can generate the address more efficiently than the generic code in reload can do.

It should always be safe for LEGITIMIZE_RELOAD_ADDRESS to do nothing. For your problem I'm sure it's a total red herring.


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