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

[Ramkumar Ramachandra via llvm-dev]

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>