public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Meissner <meissner@linux.ibm.com>,
	gcc-patches@gcc.gnu.org, David Edelsohn <dje.gcc@gmail.com>
Subject: Re: [PATCH, V4] PowerPC Turn on -mpcrel by default for -mcpu=future
Date: Tue, 21 Apr 2020 14:15:15 -0500	[thread overview]
Message-ID: <20200421191515.GV26902@gate.crashing.org> (raw)
In-Reply-To: <20200421180334.GA19690@ibm-tinman.the-meissners.org>

On Tue, Apr 21, 2020 at 02:03:34PM -0400, Michael Meissner wrote:
> On Tue, Apr 07, 2020 at 05:58:01PM -0500, Segher Boessenkool wrote:
> > > +  /* Enable -mprefixed by default on 64-bit 'future' systems.  */
> > > +  if (TARGET_FUTURE && TARGET_POWERPC64
> > > +      && (rs6000_isa_flags_explicit & OPTION_MASK_PREFIXED) == 0)
> > > +    rs6000_isa_flags |= OPTION_MASK_PREFIXED;
> > 
> > I don't understand why only for 64 bit?
> 
> I have doubts whether PC-relative really works with 32-bit.  I suspect that you
> may see some hidden wrap around issues if an address crosses the 32-bit
> boundary.

Which is undefined behaviour *anyway*?  In C, etc.

The Power ISA makes it very clear how this behaves, though:

5.7.1 32-Bit Mode
The computation of the 64-bit effective address is inde-
pendent of whether the thread is in 32-bit mode or
64-bit mode. In 32-bit mode (MSR[SF]=0), the high-order
32 bits of the 64-bit effective address are treated as
zeros for the purpose of addressing storage. This
applies to both data accesses and instruction fetches. It
applies independent of whether address translation is
enabled or disabled. This truncation of the effective
address is the only respect in which storage accesses
in 32-bit mode differ from those in 64-bit mode.

> Given the simulator I have access to only runs Linux 64-bit, I have
> no way of testing it.  I would prefer to not put in code that I can't test.

Think of it as "this cannot happen", if that makes you feel better?  :-)

> But if the only way to get the patch in is to remove the test, I can remove it.


Segher

      reply	other threads:[~2020-04-21 19:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06 16:52 Michael Meissner
2020-04-06 22:21 ` will schmidt
2020-04-07 22:58 ` Segher Boessenkool
2020-04-21 18:03   ` Michael Meissner
2020-04-21 19:15     ` Segher Boessenkool [this message]

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=20200421191515.GV26902@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=meissner@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).