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 894853856DCB for ; Mon, 9 May 2022 17:15:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 894853856DCB 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 0341E40755C2; Mon, 9 May 2022 17:15:53 +0000 (UTC) Date: Mon, 9 May 2022 20:15:52 +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: <35ad515d-4970-1861-30c6-4a72d635c28@ispras.ru> References: <20220417185113.25780-1-jakmobius@gmail.com> <381c469c-516e-808f-f811-314eddaf2ba9@ispras.ru> <5e8789c-7394-7521-33ae-70375d9a28@ispras.ru> 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: Mon, 09 May 2022 17:16:00 -0000 On Mon, 9 May 2022, Jan Hubicka wrote: > > On second thought, it might be better to keep the assert, and place the loop > > under 'if (optimize)'? > > The problem is that at IPA level it does not make sense to check > optimize flag as it is function specific. (shlib is OK to check it > anywhere since it is global.) > > So I think we really want to run the code only at the WPA time > (symtab_state>=IPA_SSA) and we want to see what is optimization flag of > those function referring the variable since that is what decided codegen > we will produce. I'm not sure about the latter. Are you suggesting we give up on upgrading general-dynamic to local-dynamic if in a mixed-O scenario there is at least one -O0 function referring to the variable? Why? That function will end up even more deoptimized if we do that! Alexander