This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [m32c] IRA reload failures in libstdc++
Quoting DJ Delorie <dj@redhat.com>:
m32c has no problem loading a 24-bit register from a 32-bit memory
location.
The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
Does that mean that Sd* is as good as m?
It had crossed my mind that you could use LEGITIMIZE_RELOAD_ADDRESS
to hide the issue, but that is not the purpose of
LEGITIMIZE_RELOAD_ADDRESS; it should be used only to improve
efficiency of reloading;
Then why isn't it called "EFFICIENCIZE_RELOAD_ADDRESS" ?
It was called LEGITIMIZE_RELOAD_ADDRESS in analogy to LEGITIMIZE_ADDRESS.
Now you could ask why that macro wasn't called EFFICIENCIZE_ADDRESS .
I would say that is so because efficiencize is not a word.
The idea is that the compiler has generic code to transform a non-legitimate
address into a legitimate address, which it will use by default, but if
the target wants to override this code, it can do so with the
LEGITIMATE_ADDDRESS macro - if there was a specific macro to override
the code to efficiencize addresses, that might be called EFFICIENCIZE_ADDRESS.
There's code in reload.c around line 5948 (find_reloads_address_1)
that tests that case (subregs), but doesn't find anything unusual
about it and defers to the generic "reload the contents" case. The
comment on else second clause implies it should do what we want, but
it doesn't work right - there *are* two registers in A_REGS, but you
can't concatenate them, nor would they be a legitimate address if you
did.
The salient fact here is that there is no register r in A_REGS such
that HARD_REGNO_MODE_OK (rn, PSImode) && !fixed_regs[rn] is true
for [ r , r + HARD_REGNO_NREGS (r, PSImode) ) .
I would think that if that condition can be fulfilled, it will usually
be fulfilled by the first register in the class, so I would expect a simple
linear search to be generally fast if the condition is fulfilled. If the
class is too small, the search should be over soon, too. And if the search
fails, you currently get reload errors.
On the other hand I have to say that I've often though how stupid it is that
reload doesn't generally reload in the smaller mode; if reloading a narrower
subreg would be straightforward, reloading the inside of the SUBREG causes
a lot of unnecessary code to be generated. The only redeeming point is
that this doesn't really happen all that often - stuff like floating-point
emulation is so hopelessly inefficient when compiled by gcc that you have to
write in assembler anyway if you want speed.
Unfortunately, sometimes reloading a wider inside part of a SUBREG is
required because of quirks of the hardware or the gcc port - or sometimes
because of reload being tied to memory addresses being valid or not
depending only on access mode rather on reload register class.
So, personally, I would welcome a new macro or hook to make the decision
to reload the inside or the outside of the subreg target-dependent.