[llvm-commits] [LLVMdev] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)

[Rafael Espíndola]

> The point still stands, though: that code requires the tls_model
> attribute to be respected; if the compiler chooses local-exec instead,
> it won't be dlopen-able.

This is a fairly contrived use case, and an extension of a gcc extension.

> I think it adds value to make the behaviour the same as GCC's. And
> it's not like the difference wouldn't be detectable: the asm is
> different, the .o files are different, and the code from the non-PIC
> i386 shared lib example wouldn't load with dlopen.

The gcc behavior is inconsistent with the linker and, as you found
out, with itself.

> The question is what value it adds to make it work differently from GCC.
>
>> Secondary arguments for going without a "default" value are:
>>
>> * It is much easier to add it if we find that we do need it than it is
>> to remove it if we convince ourselves that it is redundant.
>
> I don't think it is redundant.
>
> (And removing the "default" value while preserving backwards
> compatibility just means we've wasted one value in the bitcode
> encoding.)

No, to do the upgrade without changing the final result, the value
that "default" should map too depends a lot on the context. It depends
if we are in a "compiler context" or a "linker context". It depends on
-fPIC or not, and that information is not normally available during an
upgrade.

>
> I don't know enough about how the LTO code works to comment on this one.

The summary is that in LTO we are part of the linker, so if the linker
can do an optimization, so can we.

Before you wrote

> I don't have any more compelling reasons than those, and I don't feel
> super strongly about this, so I'm willing to give in if others
> disagree with me :)

What about this:

* We implement this first without a 'default' value. This covers the
one real world use case I know of (libc knowing it is not dlopened).
* I am to blame if we missed some other use case and commit to
implementing it in the future if/when it is found :-)

> Thanks,
> Hans

Cheers,
Rafael