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, 7 Apr 2020 17:58:01 -0500	[thread overview]
Message-ID: <20200407225801.GE26902@gate.crashing.org> (raw)
In-Reply-To: <20200406165204.GA15583@ibm-tinman.the-meissners.org>

Hi!

On Mon, Apr 06, 2020 at 12:52:04PM -0400, Michael Meissner wrote:
> Commit message:
> Enable -mpcrel for -mcpu=future if it is allowed by the ABI.

You can just put this in the mail subject.  No dot at the end, but start
with a capital, an put a subsystem label on it:

Subject: rs6000: Enable -mpcrel for -mcpu=future if it is allowed by the ABI

(As you see, it is a bit long already).

> 2020-04-06  Michael Meissner  <meissner@linux.ibm.com>
> 
> 	* config/rs6000/linux64.h (PCREL_SUPPORTED_BY_OS): Enable
> 	prefixed PC-relative addressing if the ABI supports it.
> 	* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Do not
> 	set OPTION_MASK_PREFIXED here.
> 	* config/rs6000/rs6000.c (rs6000_option_override_internal): Enable
> 	OPTION_MASK_PREFIXED and OPTION_MASK_PCREL on -mcpu=future by
> 	default if the current ABI allows the options.

The changelog goes at the *end* of the commit message.  Oh, there was
nothing more?

> --- /tmp/XzRKno_rs6000-cpus.def	2020-04-03 17:15:05.068676928 -0400
> +++ gcc/config/rs6000/rs6000-cpus.def	2020-04-03 17:00:50.115550614 -0400
> @@ -75,10 +75,14 @@
>  				 | OPTION_MASK_P8_VECTOR		\
>  				 | OPTION_MASK_P9_VECTOR)
>  
> -/* Support for a future processor's features.  Do not enable -mpcrel until it
> -   is fully functional.  */
> +/* Support for a future processor's features.  Do not set OPTION_MASK_PREFIXED
> +   or OPTION_MASK_PCREL here.  Those options are enabled in the function
> +   rs6000_option_override if the ABI supports them.  */

I am still not happy with that, and it should be fixed.  But, let's do
that later then.

The ISA mask should say what features are supported.  If we choose not
to use some we should do that elsewhere, in option_override for example.
Expressing only 95% of the features in the ISA masks is the worst of
both worlds.

> +/* Flags that need to be turned off if -mno-future.  */
> +#define OTHER_FUTURE_MASKS	(OPTION_MASK_PCREL			\
>  				 | OPTION_MASK_PREFIXED)
>  
>  /* Flags that need to be turned off if -mno-future.  */

And right after this is already a define for OTHER_FUTURE_MASKS.  Did
you mismerge this?  Please correct and repost.

> +  /* 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?

> +#ifdef PCREL_SUPPORTED_BY_OS
> +  /* If the ABI has support for PC-relative relocations, enable it by
> +     default.  */
> +  if (PCREL_SUPPORTED_BY_OS
> +      && (rs6000_isa_flags_explicit & OPTION_MASK_PCREL) == 0)
> +    rs6000_isa_flags |= OPTION_MASK_PCREL;
> +#endif

No #ifdef at uses please, unless there is a reason (there is none here
afaics).

The #ifndef you had before for the default definition was fine.  The
#undef you had for a non-default definition was not: it hides problems,
it never helps.


Segher

  parent reply	other threads:[~2020-04-07 22:58 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 [this message]
2020-04-21 18:03   ` Michael Meissner
2020-04-21 19:15     ` 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=20200407225801.GE26902@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).