From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id D1A8B3858D3C for ; Thu, 5 May 2022 14:41:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D1A8B3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id AE65840D4004; Thu, 5 May 2022 14:41:07 +0000 (UTC) Date: Thu, 5 May 2022 17:41:07 +0300 (MSK) From: Alexander Monakov To: Jan Hubicka cc: Martin Jambor , Artem Klimov , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] ipa-visibility: Optimize TLS access [PR99619] In-Reply-To: Message-ID: References: <20220417185113.25780-1-jakmobius@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, 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 14:41:18 -0000 On Thu, 5 May 2022, Jan Hubicka wrote: > > 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? Well, for an -O0 function it doesn't matter how many different TLS variables it is referencing. The interesting case is an -O2 function referencing one local-dynamic TLS variable. > I guess then a correct answer would be to search for such references. Presumably at RTL generation time, i.e. let the middle end discover the most specific TLS access model, and then selectively downgrade local-dynamic to global-dynamic when lowering an -O0 function. > 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). They have different relocations, so there's an increase in number of GOT entries, but otherwise I don't think there's any problem. Alexander