DIP 45 - approval discussion

[Walter Bright]

On 11/10/2013 1:50 PM, Benjamin Thaut wrote:
> You completely ignored my inlining argument. Lets assume there is some small
> function that qualifies for inlining but accesses a TLS variable marked with the
> export attribute. The compiler now wants to cross-module inline it. How does it
> do that, if there is no way to access TLS variables across DLL boundaries? The
> obvious solution would be, not do it at all.

Right.

> That means to disqualify all
> functions that do TLS access for cross-module inlining, because the compiler
> can't know if they are linked in from a static or shared library.

The compiler would benefit from knowing which modules are from a shared library, 
and it needs to anyway in order to distinguish between dllimport and dllexport.


> With D beeing a language that aims for performance, do we really want to do that?

The trouble is, the proposed solution for exporting TLS variables is to wrap the 
access in a function that is not inline-able anyway. For performance oriented 
code, the user would be better off to write his own wrapper, and then hoist the 
call out of the hot spot, and use a pointer to the TLS variable in the hot spot.

As a general rule, if code has a "hot spot" that crosses a DLL boundary, there 
is going to be performance problems with it regardless. I don't think this is a 
problem that the language can solve without some effort from the user.