llvm dev - Jul 2016 - PIC preferred too strongly, even at CodeModel::Large?

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
>> 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.

Ram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jumptable_bug.ll
Type: application/octet-stream
Size: 633 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/a6b3b7d5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jumptable_bug.s
Type: application/octet-stream
Size: 1058 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/a6b3b7d5/attachment-0001.obj>

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>

Hi All,

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.

ELF on Darwin in the JIT may work, especially for simple cases, but
definitely isn't supported.

- Lang.


On Fri, Jul 29, 2016 at 10:44 AM, Eli Friedman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160731/4ec97606/attachment.html>