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: [PATCH, FT32] initial support

On 05/14/2015 09:20 AM, James Bowman wrote:

On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
I cannot reproduce this with your testcase.  Please post the *exact*
testcase (nothing snipped) and the command line you used?

Making the array volatile and using optimisation helped.  Kaboom.

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?

(ft32.c line 856).
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?
I don't think so, it feels like something else to me. But I do have a larger concern that if LRA hasn't been used much, if at all, on targets that have multiple address spaces, then we may have other lurking issues.


In .ira we have:

(insn 11 7 12 2 (set (reg:SI 51)
        (const_int -900 [0xfffffffffffffc7c])) j.c:7 25 {*movsi}
     (expr_list:REG_EQUIV (const_int -900 [0xfffffffffffffc7c])
(insn 12 11 18 2 (set (reg/f:SI 50)
        (plus:SI (reg/f:SI 0 $fp)
            (reg:SI 51))) j.c:7 2 {addsi3}
     (expr_list:REG_DEAD (reg:SI 51)
        (expr_list:REG_EQUIV (plus:SI (reg/f:SI 0 $fp)
                (const_int -900 [0xfffffffffffffc7c]))

Where r51 will get a hard reg, but r50 will not. This is confirmed by looking at the coloring dump in .ira:

 Loop 0 (parent -1, header bb2, depth 0)
    bbs: 4 3 2
    all: 0r45 1r54 2r50 3r51 4r48 5r44 10r52 11r43
    modified regnos: 43 44 45 48 50 51 52 54
    Pressure: GENERAL_REGS=6
    Hard reg set forest:
      0:( 2-29)@0
        1:( 2-6 8-29)@87680
      Spill a2(r50,l0)

So r50 gets spilled to memory. That's going to cause insn 12 to have an output reload because it can't store into memory directly.

        Choosing alt 1 in insn 12:  (0) r  (1) r  (2) r {addsi3}
Creating newreg=55 from oldreg=50, assigning class GENERAL_REGS to r55
   12: r55:SI=$fp:SI+r51:SI
      REG_DEAD r51:SI
      REG_EQUIV $fp:SI-0x384
    Inserting insn reload after:
   32: r50:SI=r55:SI

So we're going to use r55 to hold the result of the arithmetic, then shove it into the stack slot allocated for r50. That all seems normal.

But for some reason things blow up after that, it's almost as if LRA doesn't like the trival reg-reg copy emitted to handle the output reload.

At this point I'd recommend committing the port as-is and attacking LRA as a follow-up.


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