[PATCH] D15635: AsmPrinter: Produce PC-relative cstexprs when possible.

[Joe Groff via llvm-commits]

On Wed, Jan 20, 2016 at 11:26 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 20 January 2016 at 14:13, Joe Groff <arcata at gmail.com> wrote:
> > jckarter added a comment.
> >
> > No worries, thanks for the feedback, Rafael. I was following the example
> of how we handle rewriting relative references to GOT-equivalent globals
> into GOTPCREL relocations, which also happens in the AsmPrinter. It'd be
> great if MC could be made smarter about choosing relocations. The issue
> also impacts Mach-O, though unlike ELF, Mach-O does support generalized
> subtractor relocations, so it isn't a showstopper there. These subtractor
> relocations have however been giving me heartache, exposing unused corners
> of Darwin's ld and MCJIT, so I think it's better to favor PCREL relocation
> if we can get them on Mach-O too, since those are much better exercised.
>
> I fixed the ELF case in r258329.
>

Fantastic, thanks!


>
> Can you give an example in assembly where your transformation would
> avoid a subtractor in MachO? I tested with
>
> .section __DATA,__const
> L_foo:
> .long L_bar-L_foo
> .section __TEXT,__cstring,cstring_literals
> L_bar:
>
> and even with two L symbols I get a subtractor.
>

You're right. Even using '.' appears to cause mc to produce a subtractor:

.data
L_foo:
  .long L_bar - .

.text
L_bar:
  .long 0

I had honestly only cmp'ed the output of 'L_bar - L_foo' and 'L_bar - .',
without looking at the actual relocations. Sorry.

-Joe


>
> Right now I cannot remember why the GOT-like optimization is done
> during asm printing. I remember it is an optimization to avoid having
> to add a feature to the IR, but I cannot remember why it was not
> implemented directly in MC. Bruno, do you remember?
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160120/6cce0c77/attachment.html>