[llvm] r290694 - [COFF] Use 32-bit jump table entries in .rdata for Win64

[Reid Kleckner via llvm-commits]

On Sun, Jan 1, 2017 at 12:07 PM, Joerg Sonnenberger <joerg at bec.de> wrote:

> On Sun, Jan 01, 2017 at 09:42:29AM -0800, David Majnemer wrote:
> > On Sun, Jan 1, 2017 at 7:16 AM, Joerg Sonnenberger via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> >
> > > On Thu, Dec 29, 2016 at 12:12:40AM -0000, Reid Kleckner via
> llvm-commits
> > > wrote:
> > > > Author: rnk
> > > > Date: Wed Dec 28 18:12:39 2016
> > > > New Revision: 290694
> > > >
> > > > URL: http://llvm.org/viewvc/llvm-project?rev=290694&view=rev
> > > > Log:
> > > > [COFF] Use 32-bit jump table entries in .rdata for Win64
> > >
> > > Does Windows support the large code model?
> >
> > PE-COFF has a 2GB size limit on all platforms.
>
> That doesn't exactly answer the question. Consider the MCJIT use -- is
> it possible for sections of the same compilation to end up being more
> than 2GB away from each other? If yes, the label difference code doesn't
> work, but the function-relative encoding would.
>

I think if the question is "does COFF the object file format natively
support the large code model?" then the answer is definitely no.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170103/1c010a21/attachment.html>