This is the mail archive of the gcc@gcc.gnu.org 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: [m32c] IRA reload failures in libstdc++


>  From looking at the m32c machine description I got the impression
> that you can't directly load A_REGS in PSImode from a PSImode subreg
> of a SImode memory location, but maybe I was mistaken.

The big problem with m32c (--mcpu=m32c) is that pointers are 24 bits,
which doesn't correspond to any C integral type.  The address in
question is illegal because it's trying to use an SImode value as a
PSImode pointer.  The (subreg ...) in this case is a real operation,
not a paradoxical or same-size subreg, so it needs to be extracted
from the operation and done as an insn.  That insn can be a "no-op" if
the right registers are used, but that's the backend's problem.

m32c has no problem loading a 24-bit register from a 32-bit memory
location.

> 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" ?

> if you can get the same reloads with the macros and hooks that drive
> the generic reload machinery, that is preferred.

I put traces on all of them; the subreg is only passed to legitimize.
The other ones either get the whole MEM or they get just the REG.

> What I was actually talking about was a patch to reload itself to
> make it reload the SUBREG:PSI instead of the inside of the subreg.

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.  M32C has very complex register classes, it might have uncovered
a bug there.

FYI, with my legitimize patch (good or bad ;) and -fno-ivopts,
m32c-elf-gcc gets these results (which are as good as m32c-elf gets
these days):

-mcpu=m16c:
 48816  98.13%  PASS
     7   0.01%  XPASS
    71   0.14%  XFAIL
    70   0.14%  FAIL
   770   1.55%  UNSUPPORTED
    12   0.02%  WARNING

-mcpu=m32c:
 48465  97.43%  PASS
     7   0.01%  XPASS
    71   0.14%  XFAIL
   404   0.81%  FAIL
    10   0.02%  UNRESOLVED
   771   1.55%  UNSUPPORTED
    13   0.03%  WARNING


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