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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
