[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2 1/4] tls: add macros for coroutine-safe TLS variables
From: |
Florian Weimer |
Subject: |
Re: [RFC v2 1/4] tls: add macros for coroutine-safe TLS variables |
Date: |
Thu, 02 Dec 2021 15:57:34 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
* Peter Maydell:
> On Thu, 2 Dec 2021 at 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
>> My compiler-developer colleagues present the following case where
>> 'noinline' is not sufficient for the compiler to definitely
>> use different values of the address-of-the-TLS-var across an
>> intervening function call:
>>
>> __thread int i;
>>
>> __attribute__((noinline)) long get_ptr_i()
>> {
>> return (long)&i;
>> }
>>
>> void switcher();
>>
>> int g()
>> {
>> long a = get_ptr_i();
>> switcher();
>> return a == get_ptr_i();
>> }
>>
>> Trunk clang optimizes the comparison of the two pointers down
>> to "must be always true" even though they might not be if the
>> switcher() function has resulted in a change-of-thread:
>> https://godbolt.org/z/hd67zh6jW
>>
>> The 'optnone' attribute (clang-specific) seems to be able
>> to suppress this
>
> ...no it doesn't -- although the get_ptr_i() function is
> called both before and after, its return value is ignored
> and g() always still returns 'true'.
__attribute__ ((weak)) would mark get_ptr_i as interposable and should
act as an optimization barrier for any compiler. Unless the compiler
defaults -fno-semantic-interposition *and* feels very, very strongly
about its meaning (clang 13 doesn't seem to, despite the
-fno-semantic-interposition default even with -fpic).
Thanks,
Florian