================ @@ -18543,7 +18552,19 @@ GetTLSADDR(SelectionDAG &DAG, SDValue Chain, GlobalAddressSDNode *GA, MFI.setHasCalls(true); SDValue Glue = Chain.getValue(1); - return DAG.getCopyFromReg(Chain, dl, ReturnReg, PtrVT, Glue); + SDValue Ret = DAG.getCopyFromReg(Chain, dl, ReturnReg, PtrVT, Glue); + + if (!UseTLSDESC) + return Ret; + + const X86Subtarget &Subtarget = DAG.getSubtarget<X86Subtarget>(); + unsigned Seg = Subtarget.is64Bit() ? X86AS::FS : X86AS::GS; + + Value *Ptr = Constant::getNullValue(PointerType::get(*DAG.getContext(), Seg)); + SDValue Offset = + DAG.getLoad(PtrVT, dl, DAG.getEntryNode(), DAG.getIntPtrConstant(0, dl), ---------------- phoebewang wrote:
Quote from https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt > An alternate design in which the function called through the TLS descriptor returns not the TP offset, but rather the address of the variable of interest, could refrain from adding %gs:0 to the value returned by the call to compute the address of a symbol, and from using the %gs: prefix when accessing the variable, but it would require the use of a longer call instruction to enable proper relaxation. The call instruction would have to be 7, instead of 2 bytes long, such that the linker could relax it to `addl %gs:0, %eax'. This would make code that accesses the variable 4 bytes longer on average (5 bytes minus one used by the %gs prefix), whereas code that computes its address would be shorter by only two bytes. It's not clear such a change would be profitable. https://github.com/llvm/llvm-project/pull/83136 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
