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.
Thank you,
Patrick Marlier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100621/63a62c0a/attachment.html>
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
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! > > -ericActually, 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.