Fangrui Song via llvm-dev
2020-Dec-01 23:31 UTC
[llvm-dev] [RFC] Coroutine and pthread_self
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