[llvm-dev] PIC preferred too strongly, even at CodeModel::Large?

[Eli Friedman via llvm-dev]

On Fri, Jul 29, 2016 at 9:57 AM, Ramkumar Ramachandra <artagnon at gmail.com>
wrote:

> Eli Friedman wrote:
> > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >> We were just debugging a sporadic crash the other day, when we noticed
> >> that RIP-relative addressing was being used in a JumpTable, even when
> >> code and data were well over 4G apart. This is confusing, because we
> >> picked CodeModel::Large, and expected this to be taken care of. Isn't
> >> that what gcc would do given a Large CodeModel?
> >
> >
> > This sounds like a bug, but I can't reproduce it.  Testcase?
>
> I've attached an example with a standard switch instruction, compiled
> with `llc -code-model=large`. It produces:
>
> movslq (%rax,%rdi,4), %rsi
> addq %rax, %rsi
> jmpq *%rsi
>

Ah; I guess I actually should have spotted that.

See
https://github.com/llvm-mirror/llvm/blob/f79c57a412cf8ba35884c1d4e011e07baad334d9/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L281
.  I think you can just force it to use EK_BlockAddress for the large code
model.


> >> Second, is it okay to
> >> silently fold into Reloc::PIC_ in this case and leave the user with
> >> sporadic crashes?
> >
> >
> > Large code model and PIC should be compatible.
>
> Technically, yes. My understanding is that, instead of a cheap
> implicit $rip offset, you have to materialize the value in a register
> and do the `add`. I don't think LLVM is doing it correctly.
>
> >> Finally, can we bypass this limitation by simply
> >> appending "-elf" to our Target Triple, forcing ELF generation on all
> >> three platforms?
> >
> >
> > What exactly are you planning to do with an ELF object file on OS X?
>
> I forgot to mention: we're JIT'ting. In any case, isOSDarwin() isn't
> influenced by an extra "-elf" to the target triple.
>

Ah... I think it might have been possible to use ELF on OS X with MCJIT at
some point, but it's not really supported in any case.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/0772d3a0/attachment-0001.html>