From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53983 invoked by alias); 11 May 2015 21:59:55 -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 53974 invoked by uid 89); 11 May 2015 21:59:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 11 May 2015 21:59:53 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 2FAF9541E8F; Mon, 11 May 2015 23:59:50 +0200 (CEST) Date: Mon, 11 May 2015 22:13:00 -0000 From: Jan Hubicka To: "H.J. Lu" Cc: Jeff Law , Jan Hubicka , Alexander Monakov , GCC Patches , Rich Felker Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt Message-ID: <20150511215950.GD35526@kam.mff.cuni.cz> References: <1430757479-14241-1-git-send-email-amonakov@ispras.ru> <1430757479-14241-6-git-send-email-amonakov@ispras.ru> <20150510165943.GI9659@atrey.karlin.mff.cuni.cz> <555112D7.8020809@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-05/txt/msg01025.txt.bz2 > >> This won't play well with LTO since fplt will become another global flag > >> while > >> it affects codegen. > > > > I know Richi explained this to me in the past, but I can't remember the > > details of why this is bad. Can you walk me through it again? > > > > I have proposed a different approach: > > https://gcc.gnu.org/ml/gcc/2015-05/msg00086.html THe RELAX_PC* approach looks indeed interesting (I still need to catch up with the thread), but to answer Jeff's question. With LTO we need to handle stuff like gcc a.c -fplt -flto -c -O2 gcc b.c -fno-plt -flto -c -Os gcc a.o b.o -flto and generaly we would like to mimmic as closely as possible what happens with non-LTO builds. That is functions originating from a.c should be -O2 optimized with PLT and functions from b.c should size optimized w/o PLT (wich makes cross module inlining fun). To do so we now attach implicit optimization/target node to each function that stores the flags used to build the unit. optimization nodes contains only those flags that are defined as Optimization. So in general if we have a flag that is about function codegen and we are able to produce function with different values of the flag in one unit, we really want to mark it as Optimization (and decide what we want to do about inlining across the flag boundary). Not all flags works like this, for example -fPIC is a global flag and then there is Richi's code in lto-wrapper that reados those options from all .o files first and somehow chose the prevailing one for the whole program. In longer term we want to eliminate as many as possible of those global flags (for exmaple -m32 can stay global as you can not mix it with -m64) and also to explicitely represent some of the flags in IL, so inlining across boundaries works as expected. Honza > > > -- > H.J.