Re: [PATCH v2] ipa-visibility: Optimize TLS access [PR99619]

[Martin Jambor <mjambor@suse.cz>]

On Fri, Aug 26 2022, Alexander Monakov wrote:
> On Fri, 26 Aug 2022, Martin Jambor wrote:
>
>> > +/* Check if promoting general-dynamic TLS access model to local-dynamic is
>> > +   desirable for DECL.  */
>> > +
>> > +static bool
>> > +optimize_dyn_tls_for_decl_p (const_tree decl)
>> > +{
>> > +  if (optimize)
>> > +    return true;
>> 
>> ...this.  This is again an access to optimize which in LTO IPA phase is
>> not really meaningful.  Can the test be simply removed?  If not (but
>> please look at why), I'd suggest to test the overall optimize level only
>> if there is a non-NULL cfun.
>
> I'd prefer to keep it. This code is also called from the front-ends when
> assigning initial TLS access model (during parsing, at the point where
> visibility attributes, if present, have not been processed yet). There
> we don't have IPA structures, but 'optimize' is set up.
>
> I also want to avoid iterating over referring functions in non-LTO mode
> where trusting 'optimize' should be fine during this IPA pass I think?

There is still the optimize attribute so in fact no, even in non-LTO
mode if there is no current function, you cannot trust the "global"
"optimize" thing.

Ideally we would assert that no "analysis" phase of an IPA pass reads
the global optimization flags, so please don't add new places where we
do.

You can either add a parameter to decl_default_tls_model to tell it
what context it is called from and IMHO it would also be acceptable to
check whether we have a non-NULL cfun and decide based on that (but here
I only hope it is not something others might object to).

Martin