<div><div dir="auto">If it’s just for JIT, you might want to try to tell it to use ELF format as the target triple. (That’s how we do it for the JuliaLang JIT, since the RTDyld support for COFF is less mature. But I’ve only tried it on x86 and amd64.)</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 10:14 Adam Kallai via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tom,<br>
<br>
Thanks for your comments and sorry for the delayed response.<br>
<br>
I've tried out to use CodeModel::Small, it seems it works, at least LLVM <br>
doesn't generate mov instructions. I think it is a good starting point. <br>
Since finally the execution reaches the linker part of JIT. By the way <br>
could it be valid if for example the CodeModel::Small is used for JIT on <br>
Windows on ARM?<br>
<br>
However the COFF ARM64 support for MC-JIT runtime dynamic linker is <br>
missing. So I started to work on that. First of all I would like to <br>
understand better how that work.<br>
<br>
Adam<br>
<br>
On 2019. 10. 03. 8:16, Tom Tan wrote:<br>
> Hi Adam,<br>
><br>
> SwiftShader calls LLVM to do JIT for ARM64. LLVM set CodeModel::Large for ARM64 in JIT mode [1] because it assumes a pointer could reach any place in 64-bit address space. The causes LLVM generating 4 MOV instructions to load 64-bit address/constant with each MOV loads 16-bit to the target. Windows ARM64 limited branch range (probably +/- 4GB which is reachable by ADRP/ADD instruction pair) so it doesn't support relocating the previous long branch (4 MOVs), both at compile/link time and load time. There are vary places in LLVM which checks CodeModel::Large and generate code accordingly [2].<br>
><br>
> Introduce new relocation types to COFF will cause interop issue with MSVC. You probably could change CodeModel for JIT and see how far SwiftShader can go.<br>
><br>
> [1]: <a href="https://github.com/llvm-mirror/llvm/blob/6e45beba86221def2571af2b4e3f00ea8b8f5643/lib/Target/AArch64/AArch64TargetMachine.cpp#L251" rel="noreferrer" target="_blank">https://github.com/llvm-mirror/llvm/blob/6e45beba86221def2571af2b4e3f00ea8b8f5643/lib/Target/AArch64/AArch64TargetMachine.cpp#L251</a><br>
> [2]: <a href="https://github.com/llvm-mirror/llvm/blob/6e45beba86221def2571af2b4e3f00ea8b8f5643/lib/Target/AArch64/AArch64InstrInfo.cpp#L1525" rel="noreferrer" target="_blank">https://github.com/llvm-mirror/llvm/blob/6e45beba86221def2571af2b4e3f00ea8b8f5643/lib/Target/AArch64/AArch64InstrInfo.cpp#L1525</a><br>
><br>
> -Tom<br>
><br>
> -----Original Message-----<br>
> From: Adam Kallai <<a href="mailto:kadam@inf.u-szeged.hu" target="_blank">kadam@inf.u-szeged.hu</a>><br>
> Sent: Wednesday, October 2, 2019 7:35 AM<br>
> To: Martin Storsjö <<a href="mailto:martin@martin.st" target="_blank">martin@martin.st</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Tom Tan <<a href="mailto:Tom.Tan@microsoft.com" target="_blank">Tom.Tan@microsoft.com</a>>; Kristof Beyls <<a href="mailto:Kristof.Beyls@arm.com" target="_blank">Kristof.Beyls@arm.com</a>>; Peter Smith <<a href="mailto:Peter.Smith@arm.com" target="_blank">Peter.Smith@arm.com</a>>; Dave Rodgman <<a href="mailto:dave.rodgman@arm.com" target="_blank">dave.rodgman@arm.com</a>><br>
> Subject: Re: fixup_aarch64_movw support for COFF AArch64<br>
><br>
> Martin,<br>
><br>
> Thanks for your suggestion.<br>
><br>
> I look at these tests, try to make them work for COFF.<br>
><br>
> Adam<br>
><br>
> On 2019. 10. 02. 12:23, Martin Storsjö wrote:<br>
>> On Wed, 2 Oct 2019, Adam Kallai wrote:<br>
>><br>
>>> I'm working Chromium targeting Windows on ARM64 platform. As a part<br>
>>> of this work I ran into an issue related to llvm in Swiftshader.<br>
>>><br>
>>> Currently fixup_aarch64_movw relocation type is not supported for<br>
>>> COFF ARM64 (AArch64WinCOFFObjectWriter). As far as I see, Microsoft<br>
>>> hasn't defined indicator for this relocation type. I haven't seen<br>
>>> documented anywhere.<br>
>>><br>
>>> For AArch32 mova/movt indicators were implemented, I'm not sure but<br>
>>> maybe we need to have something similar for AArch64?<br>
>> The AArch32 movw/movt relocation was for a true relocation, where the<br>
>> target of the relocation is a symbol that is unknown at the assembly<br>
>> stage. But for AArch64 there is no such relocation defined for COFF.<br>
>><br>
>>> Could someone give me some pointers how I could handle/fix this?<br>
>> I'm not entirely sure, but it seems like this fixup type is only used<br>
>> for absolute values that are resolved before the object file is<br>
>> written - from AArch64AsmBackend.cpp, adjustFixupValue:<br>
>><br>
>> case AArch64::fixup_aarch64_movw:<br>
>> [...]<br>
>> if (!IsResolved) {<br>
>> // FIXME: Figure out when this can actually happen, and verify<br>
>> our<br>
>> // behavior.<br>
>> Ctx.reportError(Fixup.getLoc(), "unresolved movw fixup not yet "<br>
>> "implemented");<br>
>> return Value;<br>
>> }<br>
>><br>
>> Despite this, it seems like AArch64ELFObjectWriter::getRelocType does<br>
>> return some ELF/AArch64 specific relocation types for this (but which<br>
>> never end up emitted to object files).<br>
>><br>
>> I tried adding an error in AArch64AsmBackend.cpp for this fixup type<br>
>> and running the tests in llvm/test/MC (I didn't check other parts of<br>
>> the testsuite), and it broke two tests, MC/AArch64/fixup-absolute.s<br>
>> and MC/AArch64/fixup-absolute-signed.s. And these two produce ELF<br>
>> object files without relocations.<br>
>><br>
>> So I would aim at making these two testcases work for COFF files,<br>
>> which shouldn't require making up any new COFF relocation types, at<br>
>> least not ones that would end up visible outside of the<br>
>> lib/Target/AArch64 internals.<br>
>><br>
>> // Martin<br>
>><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>