[Bug middle-end/96200] New: Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported

[carlos at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200

            Bug ID: 96200
           Summary: Implement __builtin_thread_pointer() and
                    __builtin_set_thread_pointer() if TLS is supported
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carlos at redhat dot com
  Target Milestone: ---

In glibc we implement the equivalent of __builtin_thread_pointer() and
__builtin_set_thread_pointer() to access data that is at a constant offset from
the thread pointer.

For many of the architectures that have the builtins their tls.h implementation
in glibc is greatly simplified because they can use the builtin.

We have some ABIs that are defined as having data of a certain size and
alignment at a fixed offset from the thread pointer e.g. stack_guard,
pointer_guard, TM ABI, __private_ss (split stack) etc.

In relation to restartable sequences in the linux kernel it was discussed that
it might be interesting to have an ABI that also uses TP + offset, where glibc
provides the "offset" via an API, but the user is left to do the "TP + offset"
calculation on their own.

https://lore.kernel.org/linux-api/2452161.11491.1594732791558.JavaMail.zimbra@efficios.com/
"Is there an arch-agnostic way to get the thread pointer from user-space code ?
That would be needed by all rseq critical section implementations."

We should support these two builtins for all targets that support TLS.