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

[Davide Italiano via Phabricator via llvm-commits]

davide added a comment.

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).

> All of that having been said, however, I think there is something we need to clarify about the semantics. If we allow the transformation:
> 
>   static pthread_t tid;
>    
>   int main() {
>     tid = pthread_self();
>     ...
>   }
>    
>   void foo() {
>     auto x =tid;
>     bar(x);
>     ...
>   }
>    
> 
> to:
> 
>   int main() {
>     ...
>   }
>    
>   void foo() {
>     auto x =pthread_self();
>     bar(x);
>     ...
>   }
>    
> 
> this might obviously cause problems (if foo() is called from a different thread than main). This transformation might even be reasonable for 'speculatable' functions that are cheap (as pthread_self should be).
> 
> So the semantics we need here are a little less than speculatable, or const, put somehow restricted in scope to function-local transformations.
> 
>> [1] https://sourceware.org/ml/libc-alpha/2016-04/msg00303.html




Repository:
  rL LLVM

https://reviews.llvm.org/D32782