From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 9B5CA3856DCC for ; Thu, 5 May 2022 11:56:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B5CA3856DCC Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 8A72B282E66; Thu, 5 May 2022 13:56:22 +0200 (CEST) Date: Thu, 5 May 2022 13:56:22 +0200 From: Jan Hubicka To: Alexander Monakov Cc: Martin Jambor , Artem Klimov , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] ipa-visibility: Optimize TLS access [PR99619] Message-ID: References: <20220417185113.25780-1-jakmobius@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 05 May 2022 11:56:26 -0000 > On Thu, 5 May 2022, Jan Hubicka wrote: > > > Also note that visibility pass is run twice (once at compile time before > > early optimizations and then again at LTO). Since LTO linking may > > promote public symbols to local/hidden, perhaps we want to do this only > > second time the pass is executed? > > The first pass appears to be redundant and could be avoided, yes. > > > What is the reson we avoid using LOCAL_DYNAMIC with !optimize while we > > are happy to use LOCAL_EXEC with !optimize !flag_shlib? > > It follows from how local-dynamic model is defined: we call __tls_get_addr > with an argument that identifies the current DSO (not the individual > thread-local variable), and then compute the address of the variable with > a simple addition, so when there are two or more TLS variables, we can > call __tls_get_addr just once (but at -O0 we will end up with redundant > calls). Thanks for explanation. So this is something that really depends on optimization flags of the function referring the variable rather than on optimization flags of the variable itself and only makes difference if there is -O0 function that contains more than one reference to a TLS var? I guess then a correct answer would be to search for such references. What happens when there are multiple object files with a hidden TLS var where some gts LOCAL_DYNAMIC and others GLOBAL_DYNAMIC? (Which may happen when linking together object files compiled with different versions of compiler if we go ahead with this patch on hidden symbols). Honza > > There's no such concern for local-exec vs initial-exec promotion. > > Alexander