Re: [PATCH, FT32] initial support

[Jeff Law <law@redhat.com>]

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?
>
> The FT32 target uses TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
> (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.

Anyway:

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])
         (nil)))
(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]))
             (nil))))

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
     border:
     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.

jeff