https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #54 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Julian Waters from comment #51) > Created attachment 59318 [details] > Attempt to parallelize the load from gs/fs and load of _tls_index > > I've written a slightly different version of the patch, with the following > differences > > - The configure check is not implemented yet, but will be soon. I was busy > focusing on getting other parts right first > - I've added a 'd' section flag to the .tls section to be emitted. clang > does this and according to as documentation this is required to mark a > section as a data section > - I've attempted to parallelize the part where the 2 loads can happen in > parallel. This doesn't seem to work, since it fails with an unrecognizable > insn error. My lack of knowledge of how RTL functions is really showing here It is better to emit loads separately as the candidate patch does. These loads decay to standard insn patters. Standard patterns provide additional information to the compiler (various insn attributes), so the compiler can take better decisions (e.g. instruction scheduling). > - I didn't touch the load_tp code in i386.md for this one, since that one > seems to be for Linux and would break Linux if it were changed like the > candidate patch did? No, these changes in candidate patch are OK. In addition to TLS segment reg, they generalize TLS offset. > - I know it's been mentioned that $ after .tls isn't required, but from my > memory code like .tls$XXX can be emitted, making the $ necessary. Someone > correct me if I'm wrong > - Similarly, the !DECL_P was said to not be required, but upon closer > examination, the ELF select_section seems to do that, so I've left it in > since it does look like it is used for some purpose > > A question: Does gen_rtx_SYMBOL_REF take care of the preceding _ of > _tls_index on 32 bit?
