We supported TLS loads optimization (LLVM part) at D120000
Now this patch mainly add Clang options (-mtls-load-hoist -mno-tls-load-hoist) for it.
Also we update the old llvm option to a bool option in this patch.
Differential D122558
[2/3] TLS loads optimization (hoist) xiangzhangllvm on Mar 28 2022, 12:34 AM. Authored by
Details
Diff Detail
Unit Tests Event Timeline
Comment Actions If the option is going to be on and never turned off, we don't need a clang driver option. Clang driver option has a commitment to relative stability. Comment Actions Make sense, I prefer to keep the clang driver option for customers Comment Actions This doesn't look like sufficient justification adding a new driver option for a feature which should just be enabled at all time. Comment Actions
It is not supposed to be "never turned off". BB1 / \ BB2 BB3 (with 1 tls call or more tls calls but BB is cold) (with 1 tls call) And this patch only add about 15 lines to support the driver options. (Others are refining the llvm option and test) Comment Actions The problem isn't really the amount of code needed to support the option... it's that a formally documented option needs to have clear semantics, and we need to support it forever. We really don't like options that say "turn off optimization X that has no user-visible semantics". I mean, even if you pass -mno-tls-load-hoist, we might end up hoisting anyway, depending on what you're doing with the address... Comment Actions Thank you! I begin more clear about the principle of Clang Driver option. |
clang driver options should generally have positive and negative versions (i.e. -mtls-load-hoist/-mno-tls-load-hoist).
I'm not sure I understand why we need to expose this as a clang option, though. In the initial patch, you mentioned you wanted to land it off-by-default initially... but I'm not sure why we can't just flip the internal switch to turn it on by default, and call it done.