[PATCH] D32782: Add pthread_self function prototype and make it speculatable.

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D32782#760311, @davide wrote:

> In https://reviews.llvm.org/D32782#760309, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D32782#760304, @davide wrote:
> >
> > > OK, I think I found out the cause. I guess this patch was wrong, my bad.
> > >  GCC doesn't do anything special with `pthread_self` per-se.
> > >  What GCC does is speculating the `glibc` implementation of `pthread_self` is declared with `__attribute__(const)`.
> > >  The semantic of the attribute is that of "The const attribute is specified as asserting that the function does not examine any data except the arguments. " [1]
> > >  If the function has no arguments, it has to return the same value every time.
> > >
> > > Therefore, it speculates.
> > >  I think that other libc implementation are free to not declare pthread_self with that attribute. In fact, from what I can see, the FreeBSD version doesn't use that argument.
> > >  In other words, I don't think we're allowed to do anything with `pthread_self()` in general as POSIX specifies weaks guarantees.
> >
> >
> > So there a general implication we can implement: `__attribute__(const)`. + zero arguments == speculatable?
>
>
> I'm not sure if that's the exact recipe, but yes, it seems to be on the right path.
>
> > Also, I fail to see how it would not be safe to tread pthread_self as speculatable? Same for getpid.
> > 
> > The standard says that the call always succeeds and always returns the thread id. The thread ids are opaque, and I can imagine there being multiple "self" values (pthread_equal would just return true for all of them), thus making pthread_self non-const. However, I can think of no reason why an implementation would do this, don't know of any that do, the behavior would only be observable via some non-standard interface, and I'm happy to cross that bridge if we come to it.
>
> I don't understand the bit about `getpid()`. In that case forking actually could change the value and you might end up in trouble if you rely on that to write temporary directories (as it's generally done).


Oh. You're right. Also, that seems to also rule out this as well. fork() could also change the value of pthread_self() I'd imagine.


Repository:
  rL LLVM

https://reviews.llvm.org/D32782