[llvm-dev] [RFC] Coroutine and pthread_self

[Fangrui Song via llvm-dev]

On 2020-11-24, James Y Knight via llvm-dev wrote:
>The contract for 'attribute((const))' as specified in GCC's docs may be
>open to your interpretation -- and in fact there has been a discussion on
>the GCC lists in the past about this topic: <
>https://gcc.gnu.org/legacy-ml/gcc/2015-09/msg00354.html>. But I think it's
>far too late to change to the semantics you propose. The actual semantics
>-- both as implemented and as depended upon in practice -- are that calls
>to an `__attribute__((const))` function can be arbitrarily moved, added, or
>removed within one thread of computation, but *not* globally across the
>entire program.
>
>In any case, what it lowers to in Clang is the LLVM IR function-attribute
>readnone, which I'd argue is even more clearly correct to use on an LLVM
>function returning the address of a TLS global variable. Note that llvm
>infers that property via the FunctionAttrs pass, e.g. for this function:
>@t = thread_local global i32 0, align 4
>define i32* @foo() {
>ret i32* @t
>}

According to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
and https://gcc.gnu.org/legacy-ml/gcc/2015-09/msg00365.html , in GCC there are
2 issues related to __attribute__((const)) (used by glibc and musl for pthread_self)

* whether 'const' should imply 'nothrow' (in clang, we set LLVM 'readnone' & 'nounind' attributes, but it seems https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512#c1 has a different interpretation)
* whether 'const' is allowed to read a thread-local const variable.

>
>On Tue, Nov 24, 2020 at 8:13 AM Joerg Sonnenberger via llvm-dev <
>llvm-dev at lists.llvm.org> wrote:
>
>> On Mon, Nov 23, 2020 at 05:07:49PM -0500, James Y Knight via llvm-dev
>> wrote:
>> > Special handling for pthread_self doesn't seem reasonable -- all other
>> > functions marked '__attribute__((const))' or 'readnone' have the exact
>> same
>> > problem.
>>
>> I disagree. I would strongly argue that attribute const for pthread_self
>> is a violation of the attribute contract. As seen, it rather obviously
>> depends on observable state of the program. It should be pure only.
>>
>> Joerg
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>

>_______________________________________________
>LLVM Developers mailing list
>llvm-dev at lists.llvm.org
>https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev