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

From: Jeff Law <law at redhat dot com>
To: James Bowman <james dot bowman at ftdichip dot com>, Joseph Myers <joseph at codesourcery dot com>
Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
Date: Tue, 12 May 2015 16:36:28 -0600
Subject: Re: [PATCH, FT32] initial support
Authentication-results: sourceware.org; auth=none
References: <CA9BBF0458F83C4F9051448B941B57D117152C33 at glaexch1>,<alpine dot DEB dot 2 dot 10 dot 1502032249130 dot 21283 at digraph dot polyomino dot org dot uk> <CA9BBF0458F83C4F9051448B941B57D117157677 at SNGEXCH1 dot ftdi dot local>,<alpine dot DEB dot 2 dot 10 dot 1502111702190 dot 24912 at digraph dot polyomino dot org dot uk> <CA9BBF0458F83C4F9051448B941B57D117193228 at glaexch3>,<alpine dot DEB dot 2 dot 10 dot 1502161806330 dot 17790 at digraph dot polyomino dot org dot uk> <CA9BBF0458F83C4F9051448B941B57D117234A24 at glaexch1>,<5540658A dot 9040608 at redhat dot com> <CA9BBF0458F83C4F9051448B941B57D117B98521 at glaexch3>,<55511270 dot 70708 at redhat dot com> <CA9BBF0458F83C4F9051448B941B57D117B9A589 at glaexch3>

On 05/12/2015 04:17 PM, James Bowman wrote:

On 05/08/2015 06:04 PM, James Bowman wrote:

Are you using LRA or reload?  The former is definitely preferred and for
a simple target like this, I'd expect the transition to be very easy.


I'm using reload. Attempting to naively switch on LRA resulted in
    internal compiler error: Max. number of generated reload insns per insn is achieved (90)
so I would be very interested in a pointer an LRA clues.D Thanks.

Vladimir Makarov would be the best contact point.  I'm a bit surprised
you ran into this issue given the simplicity of the port.

I'd minimize the testcase, then enable debugging dumps, then look at the
insn that's causing LRA to loop.  If Vlad helps, he's probably going to
want that minimized testcase as well, so it's time well spent.


It seems that with whenever a function's frame is bigger than 512 bytes,
LRA loops.  Likely this causes a problem because there is no actual
instruction for subtracting constants more than 512.  However, there is a
"link" pattern that allows this. It is puzzling.

Is the subtraction part of the prologue/epilogue or some addresscalculation elsewhere in the code?

What do you do prior to reload for subtracting a large constant?Presumably you copy it into a register then do a reg-reg subtraction?

You might start by setting a breakpoint in lra_emit_add and see whatkinds of insns its emits. If you're getting in there, I'd hazard aguess that it's generating reload insns that themselves need reloads.


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.

Not sure yet :-) We really want to get away from the reload path andone way is to stop accepting ports that use it. We've done similarthings in the past with other deprecated codepaths.

It really depends on the complexity of getting LRA working for thetarget and given what I saw when looking at the port, I don't believe itshould be much work.


Thanks.

--
James Bowman
FTDI Open Source Liaison

Follow-Ups:
- Re: [PATCH, FT32] initial support
  - From: Mike Stump

References:
- Re: [PATCH, FT32] initial support
  - From: Jeff Law
- RE: [PATCH, FT32] initial support
  - From: James Bowman

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