tree 5ad5ef5582072bd4aa02feb826900304839f153a
parent 29005f52b3501c489cb1653506cd479d5a178e98
author Cherry Zhang <cherryyz@google.com> 1563222385 -0400
committer Cherry Zhang <cherryyz@google.com> 1563376588 +0000

gollvm: intrinsify runtime.getg

Currently, getg is implemented in C, which loads the thread-local
g variable. Calling getg from Go, which is somewhat frequent in
the runtime, is not inlineable. This CL lets the compiler
generate inlined load for getg. We do this in the middle-end
instead of the frontend because currently we can only do this
safely in gollvm, not gccgo.

The concern is that The backend may choose to cache the TLS
address in a register or on stack. If a thread switch happens,
the cache will become invalid. Currently, there seems no way to
tell the backend to disable or invalidate the cache, for both GCC
and LLVM backend.

However, in LLVM, the caching happens in SelectionDAG, where it
CSEs the TLS address for multiple loads in the same basic block.
It does not CSE the TLS address across multiple basic blocks. So
we are safe if we can ensure there is at most one load of g in a
block. If there are more than one, we replace it with a call of
runtime.getg (i.e. undoing the // inlining). We introduce a
backend pass to do this.

For TLS access in PIC mode, currently LLVM generates assembly
code that contains detached data16 prefixes, which causes the
assembler to emit warnings. This doesn't seem to cause any
actual problems, besides cluttering outputs.

Change-Id: Ib3969470cc838c84f993dece3716399839b69959
Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/186257
Reviewed-by: Than McIntosh <thanm@google.com>