[llvm-branch-commits] [llvm] [X86] Avoid generating nested CALLSEQ for TLS pointer function arguments (PR #106965)

[Jay Foad via llvm-branch-commits]

jayfoad wrote:

> > This sounds sketchy to me. Is it really valid to enter a second call inside another call's CALLSEQ markers, but only if we avoid adding a second nested set of markers? It feels like attacking the symptom of the issue, but not the root cause. (I'm not certain it's _not_ valid, but it just seems really suspicious...)
> 
> From what I've gathered from the source comments and the [patch](https://github.com/llvm/llvm-project/commit/228978c0dcfc9a9793f3dc8a69f42471192223bc) introducing the code that inserts these CALLSEQ markers for TLSADDRs, their only point here is to stop shrink-wrapping from moving the function prologue/epilogue past the call to get the TLS address. This should also be given when the TLSADDR is in another CALLSEQ.
> 
> I am however by no means an expert on this topic; I'd appreciate more insights on which uses of CALLSEQ markers are and are not valid (besides the MachineVerifier checks).

I also wondered about this. Are there other mechanisms that block shrink wrapping from moving the prologue? E.g. what if a regular instruction (not a call) has to come after the prologue, how would that be marked? Maybe adding an implicit use or def of some particular physical register would be enough??

https://github.com/llvm/llvm-project/pull/106965