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 5A6E83858434 for ; Thu, 5 May 2022 10:50:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5A6E83858434 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 4E9F4282E84; Thu, 5 May 2022 12:50:47 +0200 (CEST) Date: Thu, 5 May 2022 12:50:47 +0200 From: Jan Hubicka To: Martin Jambor Cc: Artem Klimov , amonakov@ispras.ru, 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, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT 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 10:50:54 -0000 > > @@ -872,6 +872,22 @@ function_and_variable_visibility (bool whole_program) > > } > > } > > } > > + FOR_EACH_VARIABLE (vnode) > > + { > > + tree decl = vnode->decl; > > + > > + /* Optimize TLS model based on visibility (taking into account > > + optimizations done in the preceding loop), unless it was > > + specified explicitly. */ > > + > > + if (DECL_THREAD_LOCAL_P (decl) > > + && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl))) > > + { > > + enum tls_model new_model = decl_default_tls_model (decl); > > + gcc_checking_assert (new_model >= decl_tls_model (decl)); > > + set_decl_tls_model (decl, new_model); > > + } > > + } > > > > decl_default_tls_model depends on the global optimize flag, which is > almost always problematic in IPA passes. I was able to make your patch > ICE using the vis-attr-hidden.c testcase from your patch with: > > mjambor@virgil:~/gcc/small/tests/tls$ ~/gcc/small/inst/bin/gcc -O2 -fPIC -flto -c vis-attr-hidden.c > mjambor@virgil:~/gcc/small/tests/tls$ ~/gcc/small/inst/bin/gcc -fPIC -O0 -shared -flto vis-attr-hidden.o > during IPA pass: whole-program > lto1: internal compiler error: in function_and_variable_visibility, at ipa-visibility.cc:888 > 0x25f48c0 function_and_variable_visibility > /home/mjambor/gcc/small/src/gcc/ipa-visibility.cc:888 > 0x25f4b33 whole_program_function_and_variable_visibility > /home/mjambor/gcc/small/src/gcc/ipa-visibility.cc:938 > 0x25f4bda execute > /home/mjambor/gcc/small/src/gcc/ipa-visibility.cc:986 > Please submit a full bug report, with preprocessed source (by using -freport-bug). > Please include the complete backtrace with any bug report. > See for instructions. > lto-wrapper: fatal error: /home/mjambor/gcc/small/inst/bin/gcc returned 1 exit status > compilation terminated. > /usr/bin/ld: error: lto-wrapper failed > collect2: error: ld returned 1 exit status > > Note the use of LTO, mismatching -O flags and the -shared flag in the > link step. 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? > > A simple but somewhat lame way to avoid the ICE would be to run your > loop over variables only from pass_ipa_function_and_variable_visibility > and not from pass_ipa_whole_program_visibility. > > I am afraid a real solution would involve copying relevant entries from > global_options to the symtab node representing the variable when it is > created/finalized, properly streaming them for LTO, and modifying > decl_default_tls_model to rely on those rather than global_options > itself. > > But maybe Honza has some other clever idea. Hmm, I think it is similar to the semantic_interposition flag added recently (and causing some interesting issues). What is the reson we avoid using LOCAL_DYNAMIC with !optimize while we are happy to use LOCAL_EXEC with !optimize !flag_shlib? Honza > > Also, please be careful not to unnecessarily commit trailing blank > spaces, the empty lines in your patch are not really empty. > > Martin