[LLVMdev] LLC Bug x86 with thread local storage
echristo at apple.com
Mon Jun 21 11:21:53 PDT 2010
On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote:
> This bug affects all LLVM versions from 2.6 to trunk :
> 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.
More information about the llvm-dev