<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 1, 2017 at 12:07 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@bec.de" target="_blank">joerg@bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-588281207938318617gmail-">On Sun, Jan 01, 2017 at 09:42:29AM -0800, David Majnemer wrote:<br>
> On Sun, Jan 1, 2017 at 7:16 AM, Joerg Sonnenberger via llvm-commits <<br>
> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> > On Thu, Dec 29, 2016 at 12:12:40AM -0000, Reid Kleckner via llvm-commits<br>
> > wrote:<br>
> > > Author: rnk<br>
> > > Date: Wed Dec 28 18:12:39 2016<br>
> > > New Revision: 290694<br>
> > ><br>
> > > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=290694&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-pr<wbr>oject?rev=290694&view=rev</a><br>
> > > Log:<br>
> > > [COFF] Use 32-bit jump table entries in .rdata for Win64<br>
> ><br>
> > Does Windows support the large code model?<br>
><br>
> PE-COFF has a 2GB size limit on all platforms.<br>
<br>
</span>That doesn't exactly answer the question. Consider the MCJIT use -- is<br>
it possible for sections of the same compilation to end up being more<br>
than 2GB away from each other? If yes, the label difference code doesn't<br>
work, but the function-relative encoding would.<br></blockquote><div><br></div><div>I think if the question is "does COFF the object file format natively support the large code model?" then the answer is definitely no.</div><div><br></div><div>If the question is "does LLVM support having COFF object files spread across >2GB of memory for JITing purposes?" then I'd have to defer to someone who knows more about our JIT.</div><div><br>Also, this got reverted in r290714. I'll try to investigate why it caused problems, but I think I'm going to do what MSVC does, which is to put the jump table after the function in the .text section, and use 32-bit entries. That would work with the large code model so long as no one function is >2GB. It also generates better code because it requires one less `lea disp(%rip), %reg` instruction.</div></div></div></div>