From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14298 invoked by alias); 3 Jun 2016 07:57:09 -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 14282 invoked by uid 89); 3 Jun 2016 07:57:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=funny X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 03 Jun 2016 07:57:07 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EA52AAAAD; Fri, 3 Jun 2016 07:57:03 +0000 (UTC) Date: Fri, 03 Jun 2016 07:57:00 -0000 From: Richard Biener To: Jan Hubicka cc: David Edelsohn , Prathamesh Kulkarni , GCC Patches , "William J. Schmidt" , Segher Boessenkool Subject: Re: move increase_alignment from simple to regular ipa pass In-Reply-To: <20160602150106.GA48112@kam.mff.cuni.cz> Message-ID: References: <20160602150106.GA48112@kam.mff.cuni.cz> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2016-06/txt/msg00245.txt.bz2 On Thu, 2 Jun 2016, Jan Hubicka wrote: > > On Thu, 2 Jun 2016, David Edelsohn wrote: > > > > > >>>>> Richard Biener wrote: > > > > > > >> "This would mean the pass should get its own non-Optimization flag > > > >> initialized by targets where section anchors are usually used" > > > >> IIUC should we add a new option -fno-increase_alignment and gate the > > > >> pass on it ? Um sorry I didn't understand why targets > > > >> with section anchors (arm, aarch64, ppc) should initialize this option ? > > > > > > > > Currently the pass is only run for targets with section anchors (and there > > > > by default if they are enabled by default). So it makes sense to > > > > run on those by default and the pass is not necessary on targets w/o > > > > section anchors as the vectorizer can easily adjust alignment itself on > > > > those. > > > > > > PPC does not always enable section anchors -- it depends on the code > > > model. Shouldn't this be tied to use of section anchors? > > > > It effectively is with the patch by walking all functions to see if they > > have section anchors enabled. That is unnecessary work for targets that > > fsection-anchors > Common Report Var(flag_section_anchors) > Access data in the same section from shared anchor points. Funny. I see the following on trunk: fsection-anchors Common Report Var(flag_section_anchors) Optimization Access data in the same section from shared anchor points. > flag_section_anchors is not declared as Optimiation, so it can't be function > specific right now. It probably should because it is an optimization. This > makes me wonder what happens when one function have anchors enabled and other > doesn't? Probably anchroing or not anchoring the var will then depend on what > function comes first in the compilation order and then we will need to make > backend grok the case where static var is anchored but flag_section_anchors is > off. This is because we represent the anchor with DECL_RTL, right? Maybe DECL_RTL of globals needs to be re-computed for each function... > I dunno what is the desired behaviour for LTOint together different code > models. Good question. There's always the choice to remove 'Optimization' and enforce same setting for all TUs we LTO in lto-wrapper. Richard.