public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@kam.mff.cuni.cz>
To: Alexander Monakov <amonakov@ispras.ru>
Cc: Martin Jambor <mjambor@suse.cz>,
	Artem Klimov <jakmobius@gmail.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] ipa-visibility: Optimize TLS access [PR99619]
Date: Mon, 9 May 2022 18:47:53 +0200	[thread overview]
Message-ID: <YnlFuYf4Ulnk35Lz@kam.mff.cuni.cz> (raw)
In-Reply-To: <5e8789c-7394-7521-33ae-70375d9a28@ispras.ru>

> On Mon, 2 May 2022, Alexander Monakov wrote:
> > > > --- a/gcc/ipa-visibility.cc
> > > > +++ b/gcc/ipa-visibility.cc
> > > > @@ -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
> > [snip]
> > > Note the use of LTO, mismatching -O flags and the -shared flag in the
> > > link step.
> > 
> > Ah, right. The assert is checking that we don't accidentally downgrade decl's
> > TLS access model, e.g. from local-dynamic to global-dynamic, and you've shown
> > how to trigger that. I didn't realize this code can run twice, and with
> > different 'optimize' levels.
> > 
> > I would suggest to solve this by checking if the new TLS model is stronger,
> > i.e. instead of this:
> > 
> >   gcc_checking_assert (new_model >= decl_tls_model (decl));
> >   set_decl_tls_model (decl, new_model);
> > 
> > do this:
> > 
> >   if (new_model >= decl_tls_model (decl))
> >     set_decl_tls_model (decl, new_model);
> > 
> > Does this look reasonable?
> 
> 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.

Honza
> 
> > > 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.
> > 
> > If we agree on the solution above, then this will not be necessary, after all
> > this transformation looks at optimized whole-program visibility status,
> > and so initial optimization level should not be relevant.
> 
> Alexander

  reply	other threads:[~2022-05-09 16:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-17 18:51 Artem Klimov
2022-05-02  8:51 ` Alexander Monakov
2022-05-02 16:04 ` Martin Jambor
2022-05-02 16:43   ` Alexander Monakov
2022-05-09 16:06     ` Alexander Monakov
2022-05-09 16:47       ` Jan Hubicka [this message]
2022-05-09 17:15         ` Alexander Monakov
2022-05-16 15:50         ` Alexander Monakov
2022-05-23 10:56           ` Alexander Monakov
2022-05-25  9:04             ` Jan Hubicka
2022-07-07 15:53               ` [PATCH v2] " Alexander Monakov
2022-07-20 13:04                 ` Alexander Monakov
2022-08-05 14:03                   ` Alexander Monakov
2022-08-23 15:27                     ` Alexander Monakov
2022-08-26 11:32                 ` Martin Jambor
2022-08-26 13:35                   ` Alexander Monakov
2022-08-30 11:44                     ` Martin Jambor
2022-08-30 13:19                       ` Alexander Monakov
2022-08-30 14:03                         ` Alexander Monakov
2022-09-05 10:39                           ` Martin Jambor
2022-05-02 19:28   ` [PATCH] " Martin Liška
2022-05-05 10:50   ` Jan Hubicka
2022-05-05 11:50     ` Alexander Monakov
2022-05-05 11:56       ` Jan Hubicka
2022-05-05 14:41         ` Alexander Monakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YnlFuYf4Ulnk35Lz@kam.mff.cuni.cz \
    --to=hubicka@kam.mff.cuni.cz \
    --cc=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakmobius@gmail.com \
    --cc=mjambor@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).