This is the mail archive of the gcc-patches@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: [PATCH, FT32] initial support


On Thu, May 14, 2015 at 01:44:48AM +0000, James Bowman wrote:
> > Compile with -da to get dump files, look at the .reload one (which is
> > for LRA if that is enabled), stare long and hard.  I recommend coffee.
> 
> OK! Looking more at this, the LRA is not actually looping on the link, but on an address calculation

[snip]

> And LRA loops on insn 37, repeatedly allocating a register for (reg:SI 97).

Now your job is to figure out why it does that.  It prints out for
every innstruction what alternative it chose, and why it thinks
that is a good plan or not.  Since nothing works, it puts in some
reload insns; it also shows those.  But since in your case the
reloads do not in fact solve anything, it loops.

Since you have a frame pointer, was this a -O0 compile?

[snip, working case:]

> (insn 7 11 8 2 (set (reg:SI 2 $r0)
>         (plus:SI (reg/f:SI 0 $fp)
>             (reg:SI 43))) /home/james/tmp/x.c:31 2 {addsi3}
>      (expr_list:REG_DEAD (reg:SI 43)
>         (nil)))
> 
> They look very similar. I am currently baffled. 

This doesn't need reloading the dest of the set, since it already has
a hard register.

> > > Do you think it would be easier to make the submission as is, then debug
> > > the LRA issues from that point? If so, I have attached the current patch set.
> >
> > You should add a -mlra option so other people can easily enable it, too;
> > also handy later (when it defaults to on) when LRA blows up (you can
> > workaround with -mno-lra then).
> 
> Sounds good to me. Would that be an acceptable way to get the FT32 port 
> into the tree?

I don't make those decisions.  Having -mlra is of course not enough;
but it can help you.  And it's trivial to implement, so why are we
talking about this :-)

There are other things wrong with your port as well, so you'll take some
time to fix those up anyway, and maybe the LRA issue isn't so hard at all.
Having a -mlra option is nice in any case, as long as you haven't converted
over to LRA fully.

> I am very happy to go with the general flow towards LRA,
> but at this point perhaps it may be a little early?

I think LRA should work fine for you, I didn't see anything excitingly
different from other archs in your port (but I didn't look in detail).


Do you have test results?


Segher


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