<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Feb 22, 2016 at 5:00 PM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Yeah, for most of the architectures listed there it's not particularly useful as they support direct access to TLS variables (as Joerg says later). That grep isn't representative of how the data is actually accessed. If the current address space way of specifying isn't doable on PPC then that's fine (or feels icky).</div></div></div></blockquote><div><br></div><div>It is certainly doable, but I feel icky:</div><div>1) It needs to support negative offset, which is weird when we are talking about address spaces;</div><div>2) Handling TLS is totally different from handling real ppc segments (which I assume address space is designed for);</div><div>3) TLS has a different semantic from address space (<a href="http://llvm.org/docs/CodeGenerator.html#x86-address-spaces-supported">http://llvm.org/docs/CodeGenerator.html#x86-address-spaces-supported</a>).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>That said, the basic idea of keeping around the way to access the TLS variable is pretty easy, we do some amount of this in TargetLowering::getStackCookieLocation, but we might just need to come up with a new interface there that returns the address of the stack local load rather than an offset from an address space.</div></div></div></blockquote><div><br></div>I also found a similar case - getSafeStackPointerLocation(). On X86 it's implemented in terms of address space (similar to getStackCooikeLocation), but on AArch64 it's implemented in terms of a target specific AArch64ISD::THREAD_POINTER and Intrinsic::aarch64_thread_pointer.</div><div class="gmail_quote"><div><br></div><div>To make the fix least surprising, I can either do:</div><div>1) Create PPCISD::THREAD_POINTER and Intrinsic::ppc_thread_pointer and do similar things aarch64 does; or</div><div>2) Don't create PPCISD::THREAD_POINTER, but directly calls llvm.read_register intrinsic in ppc's getStackCookieLocation(). This is the way that requires least change; or</div><div>3) Create a generic ISD::GET_GLOBAL_TLS_ADDRESS and intrinsic llvm.get_global_tls_address(), and lower them to target specific ISD. No target specific intrinsic is needed. I was wrong about ISD::GlobalTlsAddress, since it requires a GlobalValue object.</div><div><br></div><div>I prefer 3), since it's less hacky than 2) and less repetitive than 1).</div></div></div></div>