From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93976 invoked by alias); 10 Jul 2019 18:37:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 93968 invoked by uid 89); 10 Jul 2019 18:37:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy= X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Jul 2019 18:37:55 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x6AIbqwV002397; Wed, 10 Jul 2019 13:37:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x6AIbqeW002392; Wed, 10 Jul 2019 13:37:52 -0500 Date: Wed, 10 Jul 2019 18:55:00 -0000 From: Segher Boessenkool To: Michael Meissner , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com Subject: Re: [PATCH], PowerPC, Patch #6, Create pc-relative addressing insns Message-ID: <20190710183751.GF14074@gate.crashing.org> References: <20190628000602.GA24286@ibm-toto.the-meissners.org> <20190709223000.GA18842@ibm-toto.the-meissners.org> <20190710171149.GD14074@gate.crashing.org> <20190710175607.GA23932@ibm-toto.the-meissners.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190710175607.GA23932@ibm-toto.the-meissners.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00826.txt.bz2 On Wed, Jul 10, 2019 at 01:56:07PM -0400, Michael Meissner wrote: > On Wed, Jul 10, 2019 at 12:11:49PM -0500, Segher Boessenkool wrote: > > On Tue, Jul 09, 2019 at 06:30:00PM -0400, Michael Meissner wrote: > > > @@ -8760,12 +8762,34 @@ rs6000_cannot_force_const_mem (machine_m > > > static bool > > > use_toc_relative_ref (rtx sym, machine_mode mode) > > > { > > > - return ((constant_pool_expr_p (sym) > > > - && ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (sym), > > > - get_pool_mode (sym))) > > > - || (TARGET_CMODEL == CMODEL_MEDIUM > > > - && SYMBOL_REF_LOCAL_P (sym) > > > - && GET_MODE_SIZE (mode) <= POWERPC64_TOC_POINTER_ALIGNMENT)); > > > + if (!SYMBOL_REF_P (sym) || TARGET_PCREL || !TARGET_TOC) > > > + return false; > > > > Why the SYMBOL_REF test? The original didn't have any. But its comment > > says > > /* Return true iff the given SYMBOL_REF refers to a constant pool entry > > that we have put in the TOC, or for cmodel=medium, if the SYMBOL_REF > > can be addressed relative to the toc pointer. */ > > so perhaps you want an assert instead. > > The only two callers had a test for SYMBOL_REF_P. By moving it into the > function, it made the call to the function one line instead of two. But I can > go back to the previous method. It makes more sense with the param as a symbol always (the function comment says it is, too, and the "sym" name suggests it is). So yes, please go back to that. Reducing number of lines of code isn't a goal; reducing complexity is, reducing astonishment. > > > + > > > + if (constant_pool_expr_p (sym) > > > + && ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (sym), > > > + get_pool_mode (sym))) > > > + return true; > > > + > > > + return (TARGET_CMODEL == CMODEL_MEDIUM && SYMBOL_REF_LOCAL_P (sym) > > > + && GET_MODE_SIZE (mode) <= POWERPC64_TOC_POINTER_ALIGNMENT); > > > > Please don't put disparate things on one line, it was fine before. > > I'm not sure what you mean, I was just trying to break up a long if statement. "TARGET_CMODEL == CMODEL_MEDIUM" and "SYMBOL_REF_LOCAL_P (sym)" are quite different things. > > > -static GTY(()) alias_set_type set = -1; > > > +/* Return the alias set for constants stored in either the TOC or via > > > + pc-relative addressing. */ > > > +static GTY(()) alias_set_type data_alias_set = -1; > > > > Please just make a separate alias set for pcrel. The new name isn't as > > bad as just "set" :-), but "data"? That's not great either. Conflating > > toc and pcrel isn't a good thing. > > > > (Variables don't "return" anything btw). > > > > > alias_set_type > > > -get_TOC_alias_set (void) > > > +get_data_alias_set (void) > > > > This name is much worse than the old one. Just make separate functions > > for TOC and for pcrel? Or is there any reason you want to share them? > > Well in theory, an object file that contains some functions wtih pc-relative > and some with TOC (due to #pragma target or attribute), using the same data set > would flag that they are related, but I imagine in practice the two uses don't > mix. It was more of a hangover from trying to have one function to create both > addressing forms. I think it would make things quite a bit simpler if you split them up. Could you please try that? Segher