[PATCH] D14870: [ELF2] - Implemented optimizations for @tlsld and @tlsgd

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 25 07:25:32 PST 2015


grimar added inline comments.

================
Comment at: ELF/InputSection.cpp:103
@@ -102,1 +102,3 @@
+  for (size_t I = 0; I < Num; ++I) {
+    const RelType &RI = *(Rels.begin() + I);
     uint32_t SymIndex = RI.getSymbol(Config->Mips64EL);
----------------
ruiu wrote:
> grimar wrote:
> > ruiu wrote:
> > > That's too subtle. Is there any way to avoid that?
> > gold implements that via having and setting bool flag skip_call_tls_get_addr_ that skips the relocation if true. bfd uses the approach similiar to what I used. With using flag that could be done more strict I guess (we can check relocation type and symbol name). But I think there is no chance to avoid that at all. That relocation exist but should not be proccessed.
> It is okay to update the index in side the loop. What I meant by too subtle is that it is not obvious that "I" may be updated by relocateTlsOptimize. It is passed by a reference that makes it almost impossible to imagine that case.
> 
> How about this. Change the signature of relocateTlsOptimize so that it returns an integer. If the next entry needs to be skipped, it returns 1. Otherwise 0. You can add that return value to I.
Well I cant say I like this, but I dont know much better solution atm.

================
Comment at: ELF/InputSection.cpp:114
@@ -112,1 +113,3 @@
+    if (Target->isTlsLocalDynamicReloc(Type) &&
+        (!Target->isTlsOptimized(Type, nullptr))) {
       Target->relocateOne(BufLoc, BufEnd, Type, AddrLoc,
----------------
ruiu wrote:
> Remove () from (!Target->isTlsOptimized(...))
Done.

================
Comment at: ELF/InputSection.cpp:134
@@ -131,1 +133,3 @@
+    if (Target->isTlsGlobalDynamicReloc(Type) &&
+        (!Target->isTlsOptimized(Type, &Body))) {
       Target->relocateOne(BufLoc, BufEnd, Type, AddrLoc,
----------------
ruiu wrote:
> Ditto
Done.


http://reviews.llvm.org/D14870





More information about the llvm-commits mailing list