public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: <stefan@franke.ms>
To: "'Jeff Law'" <law@redhat.com>,	<gcc-help@gcc.gnu.org>
Subject: AW: make static method find_reloads_address_1(...) extern accessible
Date: Mon, 30 Sep 2019 17:25:00 -0000	[thread overview]
Message-ID: <00a401d577b4$034d16a0$09e743e0$@franke.ms> (raw)
In-Reply-To: <2af0f71b-ea6d-982e-f779-84f097fa59ad@redhat.com>



> -----Ursprüngliche Nachricht-----
> Von: Jeff Law <law@redhat.com>
> Gesendet: Montag, 30. September 2019 18:23
> An: stefan@franke.ms; gcc-help@gcc.gnu.org
> Betreff: Re: make static method find_reloads_address_1(...) extern
> accessible
> 
> On 9/30/19 6:17 AM, stefan@franke.ms wrote:
> > I've implemented LEGITIMIZE_RELOAD_ADDRESS and that implementation
> is
> > calling find_reloads_address_1.
> >
> > My implementation adds double indirect addressing to the m68k target
> > and since the use of an outer index register or offset depends on the
> > use of an inner index register or offset, since only one index
> > register and one offset is allowed per address. => The recursive
> > reload implementation does not work. So the
> LEGITIMIZE_RELOAD_ADDRESS
> > takes care of the whole address at once.
> >
> > How are the chances that a static method of reload is converted into
> > an extern accessible method, if a patch would requires it?
> If all you need is to make the routine visible, that may be OK.  THe biggest
> worry is any data structures used by find_reloads_address_1 and it's children
> and whether or not that data is valid.

It seems to work, passes the gcc.c-torture/execute tests... 

> The bigger concern I have is that we're on a path to drop reload and instead
> use LRA.  So there's a good chance that the work you do in this space doesn't
> have a significant lifetime -- doing it in LRA would be better, at least in theory
> -- and at least one other port would like to support double indirect
> addressing in LRA.
> 
> The natural question is whether or not m68k can use LRA instead of reload.
> That's predicated on converting the m68k from cc0 to MODE_CC for
> representing the condition codes.  Nobody is currently signed up to do this
> work and if nobody steps up, the m68k port will end up deprecated.

There's a bounty on bountysource for this: https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

And I am confident that an adequate implementation for LRA can be done.

Should I use the gcc development master branch (version 10 atm) or something stable for LRA?


Stefan

  reply	other threads:[~2019-09-30 17:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 12:17 stefan
2019-09-30 13:39 ` Jonathan Wakely
2019-09-30 16:23 ` Jeff Law
2019-09-30 17:25   ` stefan [this message]
2019-10-01 19:29     ` AW: " Jeff Law

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='00a401d577b4$034d16a0$09e743e0$@franke.ms' \
    --to=stefan@franke.ms \
    --cc=gcc-help@gcc.gnu.org \
    --cc=law@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).