[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#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?

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.

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