[llvm] r273019 - Change RelaxELFRelocations for llc.

James Y Knight via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 21 09:09:30 PDT 2016


On Tue, Jun 21, 2016 at 10:13 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> On 21 June 2016 at 01:39, James Y Knight <jyknight at google.com> wrote:
> > I disagree. I don't think this makes sense. Either the linker you're
> using
> > supports this feature, or it doesn't. Having it enabled for llc if your
> > linker doesn't support it is not fun.
> >
> > Further note that this also affects basically all other code using llvm
> > libraries -- other than Clang, which explicitly sets it back to false by
> > default, unless you set the ENABLE_X86_RELAX_RELOCATIONS cmake flag to
> true.
> >
> > If you want to enable the relax mode across all llvm tools in some
> > circumstances, I think it should be via moving the cmake flag from clang
> > down into llvm.
>
> But the correct answer is tool dependent.
>
> A nice consequence of this patch is that it found two different cases:
>
> * The gold plugin needs to figure out a way to check the gold version.
> For now it just uses the old relocs.
>

* The LTO support in lld always wants the new relocs since it is part
> of lld and knows lld supports them



Both of these seem like the same case: instead of using the default
(compile-time cmake flag), it has additional knowledge -- it knows the
EXACT linker that will be used to link the generate objects. So it's safe
for it to enable the feature at runtime when it knows for sure the linker
supports it, even when it was not enabled by default. That makes fine sense.


>
> I'm going to revert this commit, since I both think it intrinsically
> doesn't
> > make sense to do this, and because it's breaking some of our tools.
>
> OK. I would be ok with a cmake flag for "assume an unknown user
> supports these", but I don't think the cmake option should be used in
> TargetOptions.cpp. It should be used in tools where it makes sense. In
> tree right now that would be just tools/gold and clang.
>

Why do you think it doesn't make sense to have a global default that all
tools use? I'm not arguing that tools can't override it if they have
additional knowledge, like LTO plugins would have, but it seems to me that
all MC invocations without such knowledge should default to not using the
new relocations...and that it should be possible to change that, if you
happen to know you're on a system with a new linker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160621/d6d27de8/attachment.html>


More information about the llvm-commits mailing list