From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 72AA7385E011 for ; Thu, 2 Apr 2020 19:27:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 72AA7385E011 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 032JR1fh030641; Thu, 2 Apr 2020 14:27:01 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 032JR0eH030637; Thu, 2 Apr 2020 14:27:00 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 2 Apr 2020 14:27:00 -0500 From: Segher Boessenkool To: Michael Meissner , gcc-patches@gcc.gnu.org, David Edelsohn Subject: Re: [PATCH], Make PowerPC -mcpu=future enable -mpcrel on linux ELFv2 Message-ID: <20200402192700.GE26902@gate.crashing.org> References: <20200328013146.GA26011@ibm-tinman.the-meissners.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200328013146.GA26011@ibm-tinman.the-meissners.org> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-48.4 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 19:27:03 -0000 Hi! Some more comments: On Fri, Mar 27, 2020 at 09:31:46PM -0400, Michael Meissner wrote: > There were no regressions when I did the bootstrap and make check steps. I > verified that -mcpu=future does turn on -mprecl if you are targeting a Linux > ELF v2 system and use the medium code model. Can I check this into the master > branch? Please post the commit message you would use as well. It often can *replace* what you would type in the mail otherwise (just add some things like how it was tested, etc). > 2020-03-27 Michael Meissner > > * config/rs6000/linux64.h (PCREL_SUPPORTED_BY_OS): New macro. > * config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Do not > set -mprefixed here. OPTION_MASK_PREFIXED > * config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): New macro. It cannot be "new macro" both here and in linux64.h . This latter one is the default implementation. > (rs6000_option_override_internal): Set the -mprefixed and -mpcrel > options for -mcpu=future if these options can be used. Similar, OPTION_*. Please talk about PCREL_SUPPORTED_BY_OS. A changelog very boringly says *what* and *how*, never "why". > --- /tmp/JVBhAf_linux64.h 2020-03-27 16:27:05.478619500 -0400 > +++ gcc/config/rs6000/linux64.h 2020-03-27 16:21:56.268876616 -0400 > @@ -640,3 +640,11 @@ extern int dot_symbols; > enabling the __float128 keyword. */ > #undef TARGET_FLOAT128_ENABLE_TYPE > #define TARGET_FLOAT128_ENABLE_TYPE 1 > + > +/* Enable default support for PC-relative addressing on the 'future' system if > + we can use the PC-relative instructions. Currently this support only exits > + for the ELF v2 object file format using the medium code model. */ (exists, typo) > +#undef PCREL_SUPPORTED_BY_OS > +#define PCREL_SUPPORTED_BY_OS (TARGET_FUTURE && TARGET_PREFIXED \ > + && ELFv2_ABI_CHECK \ > + && (TARGET_CMODEL == CMODEL_MEDIUM)) There should not be an #undef here, it just hides bugs (or causes them). > --- /tmp/KyQOUN_rs6000-cpus.def 2020-03-27 16:27:05.488619427 -0400 > +++ gcc/config/rs6000/rs6000-cpus.def 2020-03-27 16:23:51.780030238 -0400 > @@ -75,11 +75,11 @@ > | 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. We do not set -mpcrel or > + -mprefixed here. These bits are set in rs6000_option_override if the system > + supports those options. */ We talked about this before. Things might be easier if you had different OPTIONs for "can the CPU do this" and "can the OS do it". > +/* Set up the defaults for whether PC-relative addressing is supported by the > + target system. */ > +#ifndef PCREL_SUPPORTED_BY_OS > +#define PCREL_SUPPORTED_BY_OS 0 > +#endif > + > /* Support targetm.vectorize.builtin_mask_for_load. */ > tree altivec_builtin_mask_for_load; > > @@ -4014,6 +4020,11 @@ rs6000_option_override_internal (bool gl > rs6000_isa_flags &= ~OPTION_MASK_FLOAT128_HW; > } > > + /* 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; This does not need OS support? > + /* If the OS has support for PC-relative relocations, enable it now. */ > + if (PCREL_SUPPORTED_BY_OS > + && (rs6000_isa_flags_explicit & OPTION_MASK_PCREL) == 0) > + rs6000_isa_flags |= OPTION_MASK_PCREL; So the user can enable pcrel even if PCREL_SUPPORTED_BY_OS is false. Okay, that is good. Maybe a better name could be found, but I can't think of one either. Segher