This is just an experience report for those who might be interested.

Given this pull request (https://github.com/D-Programming-GDC/GDC/pull/456) I thought I'd try testing a more recent GDC with my STM32 demo (https://github.com/JinShil/stm32f42_discovery_demo) and see what the state of things is.  Here are my results.

TypeInfo Stubs
===============
I was able to reduce object.d down to the following:

-- object.d --
module object;

alias size_t    = typeof(int.sizeof);
alias ptrdiff_t = typeof(cast(void*)0 - cast(void*)0);

alias string = immutable(char)[];

class Object
{ }

class TypeInfo
{ }

class TypeInfo_Const : TypeInfo
{
    size_t getHash(in void *p) const nothrow { return 0; }
}
----------------------

I wasn't able to completely omit TypeInfo because for some reason the compiler is still looking for `getHash` in `TypeInfo_Const`.

-- output from gdc --
object.d:1:1: error: class object.TypeInfo_Const is forward referenced when looking for 'getHash'
 module object;
 ^
cc1d: error: no property 'getHash' for type 'object.TypeInfo_Const'
-----------------------

But, most of the `TypeInfo` stubs are no longer required.

TypeInfo Bloat
===============
Unfortunately the TypeInfo bloat documented here (https://issues.dlang.org/show_bug.cgi?id=14758) is still there.  I suppose that's to be expected as it appears the aforementioned pull request only removed the need to write `TypeInfo` stubs.

Binary size for the STM32 demo is about 600kB when it should be more like 6kB.

Compile Speed
=============
It takes about 1 minute 30 seconds to build and link the STM32 demo resulting in a 6kB binary.  That's pretty bad, but I suspect that's a DMD CTFE problem.

Mike

On 25 June 2017 at 12:18, Mike via D.gnu <d.gnu@puremagic.com> wrote:
> This is just an experience report for those who might be interested.
>
> Given this pull request (https://github.com/D-Programming-GDC/GDC/pull/456) I thought I'd try testing a more recent GDC with my STM32 demo (https://github.com/JinShil/stm32f42_discovery_demo) and see what the state of things is.  Here are my results.
>
> TypeInfo Stubs
> ===============
> I was able to reduce object.d down to the following:
>
> -- object.d --
> module object;
>
> alias size_t    = typeof(int.sizeof);
> alias ptrdiff_t = typeof(cast(void*)0 - cast(void*)0);
>
> alias string = immutable(char)[];
>
> class Object
> { }
>
> class TypeInfo
> { }
>
> class TypeInfo_Const : TypeInfo
> {
>     size_t getHash(in void *p) const nothrow { return 0; }
> }
> ----------------------
>
> I wasn't able to completely omit TypeInfo because for some reason the compiler is still looking for `getHash` in `TypeInfo_Const`.
>
> -- output from gdc --
> object.d:1:1: error: class object.TypeInfo_Const is forward referenced when
> looking for 'getHash'
>  module object;
>  ^
> cc1d: error: no property 'getHash' for type 'object.TypeInfo_Const'

This would be coming from the front-end. The only functions that gdc itself generates are for ModuleInfo, all other artificial data and routines are emitted because the compiler was told to.


> -----------------------
>
> But, most of the `TypeInfo` stubs are no longer required.
>
> TypeInfo Bloat
> ===============
> Unfortunately the TypeInfo bloat documented here
> (https://issues.dlang.org/show_bug.cgi?id=14758) is still there.  I suppose
> that's to be expected as it appears the aforementioned pull request only
> removed the need to write `TypeInfo` stubs.
>
> Binary size for the STM32 demo is about 600kB when it should be more like 6kB.
>

Out of curiosity, is that the original built binary, or post trimming
(strip / --gc-sections)?

There might be a size optimization possibility putting the TypeInfo in comdat, perhaps we could give that a go.

There's also https://github.com/D-Programming-GDC/GDC/pull/100 - perhaps there should be a revival of that.

> Compile Speed
> =============
> It takes about 1 minute 30 seconds to build and link the STM32 demo
> resulting in a 6kB binary.  That's pretty bad, but I suspect that's a DMD
> CTFE problem.
>

Thanks for the update.

Iain.

On Sunday, 25 June 2017 at 10:44:26 UTC, Iain Buclaw wrote:
> Out of curiosity, is that the original built binary, or post trimming
> (strip / --gc-sections)?

I'm compiling with -ffunction-sections and -fdata-sections, and linking with --gc-sections.

> There might be a size optimization possibility putting the TypeInfo in comdat, perhaps we could give that a go.

Don't know what that means, but if it helps reduce dead code and doesn't have any unintended consequences, sounds good!

> There's also https://github.com/D-Programming-GDC/GDC/pull/100 - perhaps there should be a revival of that.

I'm not really interested in that because its too blunt of an instrument.  I'd like to use TypeInfo, but only if I'm doing dynamic casts or other things that require such runtime information.  Also, I'd only want the TypeInfo for the types that need it in my binary.  I've said this before but I'll repeat:  I like TypeInfo; I just don't like dead code.

Mike

On Sunday, 25 June 2017 at 10:53:35 UTC, Mike wrote:

> I'm not really interested in that because its too blunt of an instrument.  I'd like to use TypeInfo, but only if I'm doing dynamic casts or other things that require such runtime information.  Also, I'd only want the TypeInfo for the types that need it in my binary.  I've said this before but I'll repeat:  I like TypeInfo; I just don't like dead code.

Just a little more information about this.  It doesn't appear that the entire TypeInfo object is remaining in the binary.  It appears to only be the `name` of the type that the linker just can't seem to "garbage collection" from the .rodata section.

Mike

On 25 June 2017 at 13:30, Mike via D.gnu <d.gnu@puremagic.com> wrote:
> On Sunday, 25 June 2017 at 10:53:35 UTC, Mike wrote:
>
>> I'm not really interested in that because its too blunt of an instrument. I'd like to use TypeInfo, but only if I'm doing dynamic casts or other things that require such runtime information.  Also, I'd only want the TypeInfo for the types that need it in my binary.  I've said this before but I'll repeat:  I like TypeInfo; I just don't like dead code.
>
>
> Just a little more information about this.  It doesn't appear that the entire TypeInfo object is remaining in the binary.  It appears to only be the `name` of the type that the linker just can't seem to "garbage collection" from the .rodata section.
>
> Mike
>
>

Ah ha! It seems that for whatever reason, binutils can't strip strings.  But if you wrap that string around a static symbol, then has no problem removing it.

Using your small test here:  https://issues.dlang.org/show_bug.cgi?id=14758

Making the following modifications for gdc.

---
long syscall(long code, long arg1 = 0, in void* arg2 = null, long arg3 = 0)
{
    long result = void;

    asm { "syscall"
        : /* "=a" (result) ??? No output operands == asm volatile?
That seems wrong... */
        : "a" (code), "D" (arg1), "S" (arg2), "d" (arg3);
    }

    return result;
}
---

Compiling with -fdata-sections -Os shows that .rodata now only contains:

Contents of section .rodata:
 40010e 48656c6c 6f0a00                      Hello..


I'll make a formal PR when I have some time later.

Iain.

Am Sun, 25 Jun 2017 10:53:35 +0000
schrieb Mike <none@none.com>:

> 
> I'm not really interested in that because its too blunt of an instrument.  I'd like to use TypeInfo, but only if I'm doing dynamic casts or other things that require such runtime information.  Also, I'd only want the TypeInfo for the types that need it in my binary.  I've said this before but I'll repeat:  I like TypeInfo; I just don't like dead code.
> 

I think dynamic casts might actually be the only valid feature for TypeInfo. Everything else will hopefully switch to templated interfaces + CTFE introspection.

-- Johannes

On Sunday, 25 June 2017 at 10:18:04 UTC, Mike wrote:

> Compile Speed
> =============
> It takes about 1 minute 30 seconds to build and link the STM32 demo resulting in a 6kB binary.  That's pretty bad, but I suspect that's a DMD CTFE problem.

I'm been informed that this PR (https://github.com/dlang/dmd/pull/6418) may fix this.  I just my test it today if I can get it to compile with GDC.

Do you accept cherry-picked PRs like this?

Mike

On 26 June 2017 at 04:23, Mike via D.gnu <d.gnu@puremagic.com> wrote:
> On Sunday, 25 June 2017 at 10:18:04 UTC, Mike wrote:
>
>> Compile Speed
>> =============
>> It takes about 1 minute 30 seconds to build and link the STM32 demo
>> resulting in a 6kB binary.  That's pretty bad, but I suspect that's a DMD
>> CTFE problem.
>
>
> I'm been informed that this PR (https://github.com/dlang/dmd/pull/6418) may fix this.  I just my test it today if I can get it to compile with GDC.
>
> Do you accept cherry-picked PRs like this?
>

As it is a bug fix, yes I do.

Iain.

On Sunday, 25 June 2017 at 13:40:56 UTC, Iain Buclaw wrote:

> I'll make a formal PR when I have some time later.
>
> Iain.

For those who may encounter this post at a later date, the PR is here: https://github.com/D-Programming-GDC/GDC/pull/505 and it seems to solve the problem.  Yeah!

On 26 June 2017 at 04:23, Mike via D.gnu <d.gnu@puremagic.com> wrote:
> On Sunday, 25 June 2017 at 10:18:04 UTC, Mike wrote:
>
>> Compile Speed
>> =============
>> It takes about 1 minute 30 seconds to build and link the STM32 demo
>> resulting in a 6kB binary.  That's pretty bad, but I suspect that's a DMD
>> CTFE problem.
>
>
> I'm been informed that this PR (https://github.com/dlang/dmd/pull/6418) may fix this.  I just my test it today if I can get it to compile with GDC.
>
> Do you accept cherry-picked PRs like this?
>

Looks like it would be best to apply these PRs in the order listed:

https://github.com/dlang/dmd/pull/5276 https://github.com/dlang/dmd/pull/5948 https://github.com/dlang/dmd/pull/6418

Regards
Iain.