public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: John Darrington <john@darrington.wattle.id.au>
Cc: Jeff Law <law@redhat.com>, Paul Koning <paulkoning@comcast.net>,
	       Vladimir Makarov <vmakarov@redhat.com>,
	gcc@gcc.gnu.org
Subject: Re: Indirect memory addresses vs. lra
Date: Fri, 09 Aug 2019 14:17:00 -0000	[thread overview]
Message-ID: <20190809141644.GM31406@gate.crashing.org> (raw)
In-Reply-To: <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra>

Hi!

On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote:
> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote:
> 
>      Yea, it's certainly designed with the more mainstream architectures in
>      mind.  THe double-indirect case that's being talked about here is well
>      out of the mainstream and not a feature of anything LRA has targetted to
>      date.  So I'm not surprised it's not working.
>      
>      My suggestion would be to ignore the double-indirect aspect of the
>      architecture right now, get the port working, then come back and try to
>      make double-indirect addressing modes work.
>      
> This sounds like sensible advice.  However I wonder if this issue is
> related to the other major outstanding problem I have, viz: the large 
> number of test failures which report "Unable to find a register to
> spill" - So far, nobody has been able to explain how to solve that
> issue and even the people who appear to be more knowlegeable have
> expressed suprise that it is even happening at all.

No one is surprised.  It is just the funny way that LRA says "whoops I
am going in circles, there is no progress and there will never be, I'd
better stop that".  Everyone doing new ports / new conversions to LRA
sees that error all the time.

The error could be pretty much *anywhere* in your port.  You have to
look at what LRA did, and why, and why that is wrong, and fix that.

> Even if it should turn out not to be related, the message I've been
> receiving in this thread is lra should not be expected to work for
> non "mainstream" backends.

LRA is more likely to have problems in situations where it has not been
tested before.  You can replace LRA by anything else, and this isn't
limited to GCC (or software, or human endeavours, or humanity even).

> So perhaps there is another, yet to be
> discovered, restriction which prevents my backend from ever working?

From ever?  Nah, we can patch.  Also, Occam's razor says there likely
is an error in your backend you haven't found yet.

> On the other hand, given my lack of experience with gcc,  it could be
> that lra is working perfectly, and I have simply done something
> incorrectly.    But the uncertainty voiced in this thread means that it
> is hard to be sure that I'm not trying to do something which is
> currently unsupported.

Is your code in some branch in our git?  Or in some other public git?
Do you have a representative testcase?


Segher

  reply	other threads:[~2019-08-09 14:17 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-04 19:18 John Darrington
2019-08-08 16:25 ` Vladimir Makarov
2019-08-08 16:44   ` Paul Koning
2019-08-08 17:21     ` Segher Boessenkool
2019-08-08 17:25       ` Paul Koning
2019-08-08 19:09         ` Segher Boessenkool
2019-08-08 17:30       ` Paul Koning
2019-08-08 19:19         ` Segher Boessenkool
2019-08-08 19:57           ` Jeff Law
2019-08-09  8:14             ` John Darrington
2019-08-09 14:17               ` Segher Boessenkool [this message]
2019-08-09 14:23                 ` Paul Koning
2019-08-10  6:10                 ` John Darrington
2019-08-10 16:15                   ` Segher Boessenkool
2019-08-09 16:07               ` Jeff Law
2019-08-09 17:34               ` Vladimir Makarov
2019-08-10  6:06                 ` John Darrington
2019-08-10 16:12                   ` Segher Boessenkool
2019-08-12  6:47                     ` John Darrington
2019-08-12  8:40                       ` Segher Boessenkool
2019-08-12 13:35                   ` Vladimir Makarov
2019-08-15 16:29                   ` Vladimir Makarov
2019-08-15 16:38                     ` Richard Biener
2019-08-15 17:41                       ` John Darrington
2019-08-15 18:30                       ` Vladimir Makarov
2019-08-15 21:22                         ` Segher Boessenkool
2019-08-15 17:36                     ` John Darrington
2019-08-15 18:23                       ` Vladimir Makarov
2019-08-16 11:24                         ` Special Memory Constraint [was Re: Indirect memory addresses vs. lra] John Darrington
2019-08-16 14:50                           ` Vladimir Makarov
2019-08-19  7:36                             ` John Darrington
2019-08-19 13:14                               ` Vladimir Makarov
2019-08-19 15:07                                 ` Segher Boessenkool
2019-08-19 18:06                                   ` John Darrington
2019-08-20  6:56                                     ` Richard Biener
2019-08-20  7:07                                       ` John Darrington
2019-08-20  7:30                                         ` Richard Biener
2019-08-08 18:46     ` Indirect memory addresses vs. lra Vladimir Makarov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190809141644.GM31406@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc@gcc.gnu.org \
    --cc=john@darrington.wattle.id.au \
    --cc=law@redhat.com \
    --cc=paulkoning@comcast.net \
    --cc=vmakarov@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).