[LLVMdev] LLC Bug x86 with thread local storage

Patrick Marlier
Tue, 22 Jun 2010 09:11:47 -0000

On 06/21/2010 08:21 PM, Eric Christopher wrote:
> On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote:
>
>
>> Hello,
>>
>> This bug affects all LLVM versions from 2.6 to trunk :
>> http://llvm.org/bugs/show_bug.cgi?id=5081
>>
>> The workaround I found is to add this :
>>
>> Index: lib/Target/X86/X86Instr64bit.td
>>
==================================================================>> ---
lib/Target/X86/X86Instr64bit.td     (revision 105882)
>> +++ lib/Target/X86/X86Instr64bit.td     (working copy)
>> @@ -1832,6 +1832,8 @@
>>             (MOV64ri64i32 tjumptable  :$dst)>,
Requires<[SmallCode]>;
>>   def : Pat<(i64 (X86Wrapper tglobaladdr :$dst)),
>>             (MOV64ri64i32 tglobaladdr :$dst)>,
Requires<[SmallCode]>;
>> +def : Pat<(i64 (X86Wrapper tglobaltlsaddr :$dst)),
>> +          (MOV64ri32 tglobaltlsaddr :$dst)>,
Requires<[SmallCode]>;
>>   def : Pat<(i64 (X86Wrapper texternalsym:$dst)),
>>             (MOV64ri64i32 texternalsym:$dst)>,
Requires<[SmallCode]>;
>>   def : Pat<(i64 (X86Wrapper tblockaddress:$dst)),
>>
>> Unfortunately, I am 100% confident with this modification since I am
not an expert of LLVM and I doubt a bit about the conversion for 32 bit to
64bit.
>>
>> If someone could approve it or help me with this bug it will be
wonderful.
>>
> I think it just needs support in all of those cases for the tls immediate
type (for example your test would have still failed in kernel mode).  I've
gone ahead and added that in r106433 and it passes the testcase in a few
different codegen modes, but don't have any way of testing on linux at the
moment so if you can test the codegen that would be appreciated.
>
> Thanks!
>
> -eric
Actually, now llc works with the testcase but the generated code is
wrong if you try to compile it with "as".

$ as select.s
select.s: Assembler messages:
select.s:8: Error: relocated field and relocation type differ in signedness

select.s
8:        movl    $tm_nest_level at TPOFF, %ecx
9:        movq    %fs:0, %rax

This is why I set MOV64ri32 and not MOV64ri64i32 in my patch (thus this
is why I asked for correctness).

Thank you,

Patrick Marlier.