[llvm-commits] [llvm] r120225 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h lib/Target/X86/X86InstrCompiler.td test/CodeGen/X86/2009-04-24.ll test/CodeGen/X86/2009-12-11-TLSNoRedZone.ll test/CodeGen/X86/tls

[Rafael Espíndola]

>> +    BuildMI(*BB, MI, DL, TII->get(X86::DATA16_PREFIX));
>> +    BuildMI(*BB, MI, DL, TII->get(X86::DATA16_PREFIX));
>> +    BuildMI(*BB, MI, DL, TII->get(X86::REX64_PREFIX));
>> +    BuildMI(*BB, MI, DL, TII->get(X86::CALL64pcrel32))
>> +      .addExternalSymbol("__tls_get_addr",  X86II::MO_PLT)
>> +      .addReg(X86::RDI, RegState::Implicit);
>
> My understanding of ELF TLS is that the ABI requires a very specific series of machine instructions to be emitted.  If this is true, I'm concerned that some random codegen changes (e.g. live range splitting in regalloc) could cause spills or other instructions to be inserted into the middle of this carefully crafted sequence.
>
> If this is a real issue, the best approach is to have a pseudo instruction that is lowered at MCInstLowering time into the right sequence of MCInsts.

I think it is only used for doing relaxations in the linker, but yes
it is an issue. Fixed in 120263. Thanks for noticing it.

> -Chris

Cheers,
Rafael