public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	Paul Koning <paulkoning@comcast.net>
Cc: Vladimir Makarov <vmakarov@redhat.com>,
	John Darrington <john@darrington.wattle.id.au>,
	gcc@gcc.gnu.org
Subject: Re: Indirect memory addresses vs. lra
Date: Thu, 08 Aug 2019 19:57:00 -0000	[thread overview]
Message-ID: <dca38a3f-91db-9483-dd0e-0075ef501624@redhat.com> (raw)
In-Reply-To: <20190808191914.GK31406@gate.crashing.org>

On 8/8/19 1:19 PM, Segher Boessenkool wrote:
> On Thu, Aug 08, 2019 at 01:30:41PM -0400, Paul Koning wrote:
>>
>>
>>> On Aug 8, 2019, at 1:21 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>>>
>>> On Thu, Aug 08, 2019 at 12:43:52PM -0400, Paul Koning wrote:
>>>>> On Aug 8, 2019, at 12:25 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
>>>>> The old reload (reload[1].c) supports such addressing.  As modern mainstream architectures have no this kind of addressing, it was not implemented in LRA.
>>>>
>>>> Is LRA only intended for "modern mainstream architectures"?
>>>
>>> I sure hope not!  But it has only been *used* and *tested* much on such,
>>> so far. 
>>
>> That's not entirely accurate.  At the prodding of people pushing for
>> the removal of CC0 and reload, I've added LRA support to pdp11 in the
>> V9 cycle.
> 
> I said "much" :-)
> 
> Pretty much all design input so far has been from "modern mainstream
> architectures", as far as I can make out.  Now one of those has the
> most "interesting" (for RA) features that many less mainstream archs
> have (a not-so-very-flat register file), so it should still work pretty
> well hopefully.
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.

> 
>> And it works pretty well, in the sense of passing the
>> compile tests.  But I haven't yet examined the code quality vs. the
>> old one in any detail.
> 
> That would be quite interesting to see, also for the other ports that
> still need conversion: how much (if any) degradation should you expect
> from a straight-up conversion of a port to LRA, without any retuning?
I did the v850 last year where it was a wash or perhaps a slight
improvement for codesize, which is a reasonable approximation for
performance on that target.

I was working a bit on converting the H8 away from cc0 with an eye
towards LRA as well.  Given how registers overlap on the H8, the most
straightforward port should end up with properties much like 32bit x86.
  I suspect the independent addressing of the high/low register parts
might be better handled by LRA, but I wasn't going to do anything beyond
the "just make it work".

jeff

  reply	other threads:[~2019-08-08 19:57 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 [this message]
2019-08-09  8:14             ` John Darrington
2019-08-09 14:17               ` Segher Boessenkool
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=dca38a3f-91db-9483-dd0e-0075ef501624@redhat.com \
    --to=law@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=john@darrington.wattle.id.au \
    --cc=paulkoning@comcast.net \
    --cc=segher@kernel.crashing.org \
    --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).