public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: HAO CHEN GUI <guihaoc@linux.ibm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Bill Schmidt <wschmidt@linux.ibm.com>
Subject: Re: [PATCH, rs6000] Add non-relative jump table support for 64bit rs6000
Date: Thu, 30 Jul 2020 17:40:35 -0500	[thread overview]
Message-ID: <20200730224035.GA6753@gate.crashing.org> (raw)
In-Reply-To: <CAGWvnykYboF-5rd7_nVaw=e6emASj97Z3fThUH1wvDkCZuCeTw@mail.gmail.com>

Hi!

On Thu, Jul 30, 2020 at 04:35:57AM -0400, David Edelsohn wrote:
> The purpose should not be to exclude AIX.  If there is no fundamental
> limitation with use of the new tablejump design on AIX then the patch
> is not acceptable without AIX support.

The patch should work on all subtargets.  It will be controlled by an
(undocumented?) command line option, for easy experimentation, and to
make it easy to (temporarily) disable it for some subtarget.

This change will probably cause some problems on different OSes and with
different binary file formats, so it is useful to be able to control the
default separately for each, to keep things working while we figure
things out.  (It is not just AIX and Darwin, but also 32-bit Linux, the
several BSDs (which are different), bare-metal ports, the embedded OSes,
etc.)

But the goal is for this to work everywhere, yes.

We could default it to non-relative, to see what breaks ;-)

> The patch should use DOUBLE_INT_ASM_OP, not explicit ".quad".  AIX
> always is PIC.  It's not obvious to me why the patch should limit
> support to PPC64 Linux.

It's the only thing that was tested so far (I'm not sure if BE was
tested even there?)

> The section selection seems Linux/ELF
> specific, but the rest seems like a general design optimization for
> all PowerPC-based operating systems.

Yup, needs some work.


This patch should be split into the core piece, which creates the flag
and adds infrastructure etc., and patches for the subtarget-specific
pieces.  It is likely that different subtargets will want to choose
different sections for the jump tables?  But the basic things can work
everywhere, in principle.


Segher

  reply	other threads:[~2020-07-30 22:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30  5:21 HAO CHEN GUI
2020-07-30  8:35 ` David Edelsohn
2020-07-30 22:40   ` Segher Boessenkool [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-07-28  5:25 HAO CHEN GUI
2020-07-28  9:12 ` Kewen.Lin
2020-07-28 16:56   ` David Edelsohn
2020-07-30 23:42 ` Segher Boessenkool

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=20200730224035.GA6753@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=guihaoc@linux.ibm.com \
    --cc=wschmidt@linux.ibm.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).