[llvm-dev] [RFC] Coroutine and pthread_self

[James Y Knight via llvm-dev]

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
}


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201124/5d951e9f/attachment-0001.html>