[llvm] r273019 - Change RelaxELFRelocations for llc.

[James Y Knight via llvm-commits]

On Tue, Jun 21, 2016 at 12:30 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

>
> >> 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.
>
> Because the right value is tool dependent:
>
> * Lld should always use the new relocations.
> * Clang has no idea what linker will be used, so has to be very
> conservative.
> * The gold plugin might be able to figure out what linker is using it (not
> sure).
>
Agree with those.

> * Developer tools should default to the new relocations.
>
> This is where the disagreement is: I don't think that last makes sense. I
think the developer tools should also be conservative, just like clang.
Having the llvm developer tools create unlinkable object files is not
useful to me, or, I'd assert, to other developers.

I wouldn't mind if the default simply stayed "false", like it was in the
past for everything but those tools that can know it's safe. But, if
there's going to be any a default of using the new relocs in other
circumstances, I think that must be guarded behind the off-by-default cmake
flag, for now. Even for the developer tools. Probably in a couple years
from now it'll be safe to change the global default without breaking
anything, but it's really not, now...

In general when there is a need for compatibility with old external tools,
> it is always a tool that has that need, not the llvm library.
>
> Having llvm default to the new behavior and the individual tools override
> it makes it clear which tools have that requirement.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160621/19fa787d/attachment.html>