On Tuesday, 20 June 2017 at 08:31:30 UTC, Walter Bright wrote:
> On 6/19/2017 11:28 PM, Mike wrote:
>> As I understand it, this requires some cooperation between the compiler and the linker.
>
> We don't control the linker. We could do a lot if we did, but we don't.

I know, but you do know what linker features exists and how the linker works, and could generate better intermediate code that could allow the linker to more effectively identify and remove dead code.

On 6/20/2017 1:31 AM, Walter Bright wrote:
> On 6/19/2017 11:28 PM, Mike wrote:
>> As I understand it, this requires some cooperation between the compiler and the linker.
> 
> We don't control the linker. We could do a lot if we did, but we don't.

To clarify, I have experience writing and working with linkers. Doing one is a full time job for a team of one alpha programmer + a couple regular ones. You might think a linker is easy, and conceptually it is. The trouble comes from all the undocumented behaviors it is expected to do exhibit. Worse, these expectations change constantly without warning.

And lastly, we support lots of platforms. Multiply the above by the number of platforms.

It's not practical for us.

On Tuesday, 20 June 2017 at 01:51:26 UTC, Walter Bright wrote:
> Is getting a whole lot better:
>
> https://github.com/dlang/dmd/pull/6918
>
> You can now build D executables that do not link in anything from Phobos - only from the standard C library.

How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that.

On 6/20/2017 2:00 AM, ixid wrote:
> How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that.

As long as the compiler supports separate compilation, it has to emit certain information that may or may not be used by other modules.

For example, the list of imported modules, which is used by the startup code to determine the order of static construction. The compiler cannot know which of those will have static constructors and which won't.

On Tuesday, 20 June 2017 at 09:21:05 UTC, Walter Bright wrote:
> On 6/20/2017 2:00 AM, ixid wrote:
>> How far away from a purely additive, pay for what we use situation are we? It would seem like D should be BetterC out of the box, without needing any switches and as you add and use specific features and libraries it builds from that.
>
> As long as the compiler supports separate compilation, it has to emit certain information that may or may not be used by other modules.
>
> For example, the list of imported modules, which is used by the startup code to determine the order of static construction. The compiler cannot know which of those will have static constructors and which won't.

How much of that could be made lazy?

On 2017-06-20 03:51, Walter Bright wrote:
> Is getting a whole lot better:
> 
> https://github.com/dlang/dmd/pull/6918
> 
> You can now build D executables that do not link in anything from Phobos - only from the standard C library.

BTW, how are asserts handled? Isn't assert usually a macro in C?

-- 
/Jacob Carlborg

On 2017-06-20 03:51, Walter Bright wrote:
> Is getting a whole lot better:
> 
> https://github.com/dlang/dmd/pull/6918
> 
> You can now build D executables that do not link in anything from Phobos - only from the standard C library.

How is TLS handled? I know at least macOS 32bit requires the "___tls_get_addr" druntime function. Not sure if anyone cares about macOS 32bit.

Does the TLS implementation depend on druntime on any other platforms?

-- 
/Jacob Carlborg

On Tuesday, 20 June 2017 at 11:58:47 UTC, Jacob Carlborg wrote:
> On 2017-06-20 03:51, Walter Bright wrote:
>> Is getting a whole lot better:
>> 
>> https://github.com/dlang/dmd/pull/6918
>> 
>> You can now build D executables that do not link in anything from Phobos - only from the standard C library.
>
> How is TLS handled? I know at least macOS 32bit requires the "___tls_get_addr" druntime function. Not sure if anyone cares about macOS 32bit.

About macOS 32-bit. Am I the only user? Things are OK now.
The older LDCs will work targeting newer macOS 32-bit for a while I guess, so maybe 32-bit can be phased out (especially TLS which I don't use).
Not sure who else uses it.

On Tuesday, 20 June 2017 at 11:52:56 UTC, Jacob Carlborg wrote:
> On 2017-06-20 03:51, Walter Bright wrote:
>> Is getting a whole lot better:
>> 
>> https://github.com/dlang/dmd/pull/6918
>> 
>> You can now build D executables that do not link in anything from Phobos - only from the standard C library.
>
> BTW, how are asserts handled? Isn't assert usually a macro in C?

I was curious about this as well when I saw the PR.

Great to see that -betterC is getting some attention as well.

On Tuesday, 20 June 2017 at 08:36:38 UTC, Mike wrote:
> I know, but you do know what linker features exists and how the linker works, and could generate better intermediate code that could allow the linker to more effectively identify and remove dead code.

You can write a linker wrapper that will do the analysis you want, remove unneeded sections, stub symbols etc, see basic technique at https://theartofmachinery.com/2016/12/18/d_without_runtime.html