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.
