[PATCH] D120000: [1/2] TLS loads opimization (hoist)

Xiang Zhang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 2 17:41:39 PST 2022


xiangzhangllvm added a comment.

Hi, Lopes, first thank you for your attention about it.
First let me give a **short explain about TLS Variable**:
The **TLS Variable** can be simply seem as a common Global Value (for example thread_local int **thl_x**) "shared" by different threads, but each thread read/write it without affect other threads use it.
So each thread used different address of it. The function  `__tls_get_addr`  is used to get the specific address of TLS Value for current thread. (You can simply seem **thl_x** as an array **thl_x[thread_num]**,
 and seem __tls_get_addr as "return &thl_x[thread_id]"). So in same thread, the call of '__tls_get_addr' for same TLS Variable is never changed.

**How TLS Variable show in LLVM IR and MIR**:
LLVM do not distinguish TLS Variables by threads, the llvm IR/MIR directly use it like other normal Global Value. (for example load the thl_x is some like " %1 = load i32, i32* @**thl_x**, align 4"), So the called 
function  `__tls_get_addr` is invistiable to mid-end and back-end. That is why current optimization don't work on it.

AFAIK, Adding readonly & speculatable attributes let GVN optimization is not suitable. The main job of GVN is simplify the common expression to one GV. The TLS Variable is already a simple GV.
And constantHoist or LICM is also not suitable to do this (even suppose marking readonly attribute to it is no problem). Currently these 2 passes are very clean/pure to do their job, I don't want to mix them with handling TLS.

What's more current patch is simple and small, easy to control. I don't intergrate it into other optimization will be more simple or clean.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120000/new/

https://reviews.llvm.org/D120000



More information about the llvm-commits mailing list