MC: Use @IMGREL instead of @IMGREL32, which we can't parse

Nico Rieck added support for this 32-bit COFF relocation some time ago
for Win64 stuff. It appears that as an oversight, the assembly output
used "foo"@IMGREL32 instead of "foo"@IMGREL, which is what we can parse.

Sadly, there were actually tests that took in IMGREL and put out
IMGREL32, and we didn't notice the inconsistency. Oh well. Now LLVM can
assemble it's own output with slightly more fidelity.

llvm-svn: 218437
This commit is contained in:
Reid Kleckner 2014-09-25 02:09:18 +00:00
parent d355369dbb
commit 81782f0cb8
3 changed files with 3 additions and 3 deletions

View File

@ -273,7 +273,7 @@ StringRef MCSymbolRefExpr::getVariantKindName(VariantKind Kind) {
case VK_Mips_CALL_LO16: return "CALL_LO16";
case VK_Mips_PCREL_HI16: return "PCREL_HI16";
case VK_Mips_PCREL_LO16: return "PCREL_LO16";
case VK_COFF_IMGREL32: return "IMGREL32";
case VK_COFF_IMGREL32: return "IMGREL";
}
llvm_unreachable("Invalid variant kind");
}

View File

@ -2,5 +2,5 @@
@__ImageBase = external global i8
; X64: .quad "?x@@3HA"@IMGREL32
; X64: .quad "?x@@3HA"@IMGREL
@"\01?x@@3HA" = global i64 sub nsw (i64 ptrtoint (i64* @"\01?x@@3HA" to i64), i64 ptrtoint (i8* @__ImageBase to i64)), align 8

View File

@ -606,7 +606,7 @@ mov rcx, qword ptr [_g0 + 8]
fadd dword ptr "?half@?0??bar@@YAXXZ@4NA"
fadd dword ptr "?half@?0??bar@@YAXXZ@4NA"@IMGREL
// CHECK: fadds "?half@?0??bar@@YAXXZ@4NA"
// CHECK: fadds "?half@?0??bar@@YAXXZ@4NA"@IMGREL32
// CHECK: fadds "?half@?0??bar@@YAXXZ@4NA"@IMGREL
inc qword ptr [rax]
inc dword ptr [rax]