This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, FT32] initial support
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: James Bowman <james dot bowman at ftdichip dot com>
- Cc: Jeff Law <law at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 14 May 2015 12:36:12 -0500
- Subject: Re: [PATCH, FT32] initial support
- Authentication-results: sourceware.org; auth=none
- References: <55511270 dot 70708 at redhat dot com> <CA9BBF0458F83C4F9051448B941B57D117B9D21F at glaexch3> <CA9BBF0458F83C4F9051448B941B57D117BA023B at glaexch3>
On Thu, May 14, 2015 at 03:20:46PM +0000, James Bowman wrote:
> > It wants to reload pretty much everything. Looking at your code,
> > it seems you use the ancient interfaces instead of
> > TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that?
>
> The FT32 target uses TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
> (ft32.c line 856).
Ah I see.
> The FT32 itself is a Harvard architecture, and the ft32 port uses
> address spaces to distinguish between program and data memory.
>
> Of the ports that currently support LRA (arc, mips, rs6000, s380, sh) none
> use address spaces.
> Perhaps this port's use of address spaces is causing the problem?
That could certainly cause problems. I don't think it's likely
it causes all this though.
Adding some debug, it looks like LRA never calls the TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
hook? Not during the spilling it does, anyway. Here is what it
_does_ do:
Choosing alt 1 in insn 12: (0) r (1) r (2) r {addsi3}
Creating newreg=58 from oldreg=56, assigning class GENERAL_REGS to r58
12: r58:SI=$fp:SI+r55:SI
REG_DEAD r55:SI
REG_EQUIV $fp:SI-0x384
Inserting insn reload after:
32: r56:SI=r58:SI
so it decides to use the "r" constraint everywhere in that addsi3 insn, thinks
it isn't all okay yet (and it isn't, r56 was allocated to mem (see the ira dump),
has no hard reg yet), and solves it by generating an extra move. That should be
a move from the reg to mem, but it doesn't want to:
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=0,overall=608,losers=1,rld_nregs=1
alt=1: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=2: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=3: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=4: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=5: Bad operand -- refuse
alt=6: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=7: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=8: Bad operand -- refuse
Choosing alt 0 in insn 32: (0) =r (1) r {*movsi}
Creating newreg=59 from oldreg=56, assigning class GENERAL_REGS to r59
32: r59:SI=r58:SI
Inserting insn reload after:
33: r56:SI=r59:SI
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy.
"B" should match it seems?
(Why does IRA think r56 should be in memory? Yeah, good question.)
Segher