On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
> So the best option is probably to get rid of this problem by patching
> the compiler (@notypeinfo or -fnortti).

Oh, sorry, I though GDC already does that when TypeInfo is never actually used. Nevermind then, your version seems to be a solid match.

On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:

>
> After some google-fu:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
> Considering this was filed in 2000 I'd say it's not very likely to get
> fixed soon :-(
>

That looks right-on, and knowing the likely cause, I should able to engineer a workaround for now.  Nice find, and thank you!

Mike

On Thu, 15 Jan 2015 13:01:04 +0100
"Johannes Pfau via D.gnu" <d.gnu@puremagic.com> wrote:

> After some google-fu:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
> Considering this was filed in 2000 I'd say it's not very likely to get
> fixed soon :-(
and it's so forgotten that they have stupid portostory attached circa 2007. heh.

On Sunday, 11 January 2015 at 16:57:41 UTC, Johannes Pfau wrote:
>
> If you only want to disable TypeInfo for some classes that's more
> difficult:
> https://github.com/D-Programming-microD/GDC/commit/f0614bc9480dacd1ec6bb75277d280afa96e08bb

Is this good enough for a pull request upstream, or just an experiment?

On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:

> My best guess is that the strings are always placed in rodata, never in
> separate sections. If you do write("x"), "x" is also in rodata, the
> rodata section can't be removed. If you delete the write call there's
> no reference to rodata and it's possible to remove the complete
> section.
>
> After some google-fu:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
> Considering this was filed in 2000 I'd say it's not very likely to get
> fixed soon :-(
>
> So the best option is probably to get rid of this problem by patching
> the compiler (@notypeinfo or -fnortti).

Here's a filthy sed hack to workaround this bug:

1) compile to assembly:
-----------------------------------------------
gdc -S -static -frelease -fno-emit-moduleinfo -nophoboslib -nostdlib test.d --entry=main -ffunction-sections -fdata-sections -Wl,--gc-sections -o test_temp.s

2) use sed to modify the assembly, putting each
string into its own section:
-----------------------------------------------
sed -e 's/^\(\.LC[0-9]*\)\(\:\)/\.section .rodata\1\n\1\2/g' test_temp.s >test.s

3) compile the new assembly:
-----------------------------------------------
as test.s -o test.o

4) link:
-----------------------------------------------
ld test.o --entry=main --gc-sections -o test

5) verify:
-----------------------------------------------
objdump -s -j .rodata test

Contents of section .rodata:
 400168 780a                                 x.

size test
   text    data     bss     dec     hex filename
    338       0       0     338     152 test

6) execute:
------------------------------------------------
./test
x

Filthy, but cheap and effective.  Fortunately it's all automated with rdmd.

Mike

On 1/15/2015 10:31 PM, Mike via D.gnu wrote:
> On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
>
>> My best guess is that the strings are always placed in rodata, never in
>> separate sections. If you do write("x"), "x" is also in rodata, the
>> rodata section can't be removed. If you delete the write call there's
>> no reference to rodata and it's possible to remove the complete
>> section.
>>
>> After some google-fu:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
>> Considering this was filed in 2000 I'd say it's not very likely to get
>> fixed soon :-(
>>
>> So the best option is probably to get rid of this problem by patching
>> the compiler (@notypeinfo or -fnortti).
>
> Here's a filthy sed hack to workaround this bug:
>
> 1) compile to assembly:
> -----------------------------------------------
> gdc -S -static -frelease -fno-emit-moduleinfo -nophoboslib -nostdlib test.d --entry=main -ffunction-sections -fdata-sections -Wl,--gc-sections -o test_temp.s
>
> 2) use sed to modify the assembly, putting each
> string into its own section:
> -----------------------------------------------
> sed -e 's/^\(\.LC[0-9]*\)\(\:\)/\.section .rodata\1\n\1\2/g' test_temp.s >test.s
>
> 3) compile the new assembly:
> -----------------------------------------------
> as test.s -o test.o
>
> 4) link:
> -----------------------------------------------
> ld test.o --entry=main --gc-sections -o test
>
> 5) verify:
> -----------------------------------------------
> objdump -s -j .rodata test
>
> Contents of section .rodata:
>  400168 780a                                 x.
>
> size test
>    text    data     bss     dec     hex filename
>     338       0       0     338     152 test
>
> 6) execute:
> ------------------------------------------------
> ./test
> x
>
> Filthy, but cheap and effective.  Fortunately it's all automated with rdmd.
>
> Mike

The problem with this is that the TypeInfo is used for a significant number of things in the runtime, casting, allocation, and initialization just to name a few. The type info for structures is already only generated if it's allocated on the heap. I suspect though that I'm probably just too tired right now to understand the intricacies of the topic.

On Friday, 16 January 2015 at 04:31:17 UTC, Mike wrote:
> On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
>
>> My best guess is that the strings are always placed in rodata, never in
>> separate sections. If you do write("x"), "x" is also in rodata, the
>> rodata section can't be removed. If you delete the write call there's
>> no reference to rodata and it's possible to remove the complete
>> section.
>>
>> After some google-fu:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
>> Considering this was filed in 2000 I'd say it's not very likely to get
>> fixed soon :-(
>>
>> So the best option is probably to get rid of this problem by patching
>> the compiler (@notypeinfo or -fnortti).
>
> Here's a filthy sed hack to workaround this bug:
>
> 1) compile to assembly:
> -----------------------------------------------
> gdc -S -static -frelease -fno-emit-moduleinfo -nophoboslib -nostdlib test.d --entry=main -ffunction-sections -fdata-sections -Wl,--gc-sections -o test_temp.s
>
> 2) use sed to modify the assembly, putting each
> string into its own section:
> -----------------------------------------------
> sed -e 's/^\(\.LC[0-9]*\)\(\:\)/\.section .rodata\1\n\1\2/g' test_temp.s >test.s
>
> 3) compile the new assembly:
> -----------------------------------------------
> as test.s -o test.o
>
> 4) link:
> -----------------------------------------------
> ld test.o --entry=main --gc-sections -o test
>
> 5) verify:
> -----------------------------------------------
> objdump -s -j .rodata test
>
> Contents of section .rodata:
>  400168 780a                                 x.
>
> size test
>    text    data     bss     dec     hex filename
>     338       0       0     338     152 test
>
> 6) execute:
> ------------------------------------------------
> ./test
> x
>
> Filthy, but cheap and effective.  Fortunately it's all automated with rdmd.
>
> Mike

Looks like awesome wiki material :)

Am Thu, 15 Jan 2015 23:08:57 -0600
schrieb "Orvid King via D.gnu" <d.gnu@puremagic.com>:

> On 1/15/2015 10:31 PM, Mike via D.gnu wrote:
> > On Thursday, 15 January 2015 at 12:01:05 UTC, Johannes Pfau wrote:
> >
> >> My best guess is that the strings are always placed in rodata, never in separate sections. If you do write("x"), "x" is also in rodata, the rodata section can't be removed. If you delete the write call there's no reference to rodata and it's possible to remove the complete section.
> >>
> >> After some google-fu:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
> >> Considering this was filed in 2000 I'd say it's not very likely to
> >> get fixed soon :-(
> >>
> >> So the best option is probably to get rid of this problem by patching the compiler (@notypeinfo or -fnortti).
> >
> > Here's a filthy sed hack to workaround this bug:
> >
> > 1) compile to assembly:
> > -----------------------------------------------
> > gdc -S -static -frelease -fno-emit-moduleinfo -nophoboslib -nostdlib test.d --entry=main -ffunction-sections -fdata-sections -Wl,--gc-sections -o test_temp.s
> >
> > 2) use sed to modify the assembly, putting each
> > string into its own section:
> > -----------------------------------------------
> > sed -e 's/^\(\.LC[0-9]*\)\(\:\)/\.section .rodata\1\n\1\2/g' test_temp.s >test.s
> >
> > 3) compile the new assembly:
> > -----------------------------------------------
> > as test.s -o test.o
> >
> > 4) link:
> > -----------------------------------------------
> > ld test.o --entry=main --gc-sections -o test
> >
> > 5) verify:
> > -----------------------------------------------
> > objdump -s -j .rodata test
> >
> > Contents of section .rodata:
> >  400168 780a                                 x.
> >
> > size test
> >    text    data     bss     dec     hex filename
> >     338       0       0     338     152 test
> >
> > 6) execute:
> > ------------------------------------------------
> > ./test
> > x
> >
> > Filthy, but cheap and effective.  Fortunately it's all automated with rdmd.
> >
> > Mike
> 
> The problem with this is that the TypeInfo is used for a significant number of things in the runtime, casting, allocation, and initialization just to name a few.

Mike doesn't use the runtime so this is less of a problem. And in many cases the compiler already avoids TypeInfo: Default initializers are separate symbols and don't require TypeInfo. Allocation: Only GC allocation is affected, custom allocators are templates.

Casting: AFAIK only for class downcasts. This is probably the most important feature requiring TypeInfo. Here we might prefer a minimal classinfo instead of completely removing it.

> The type info for structures is
> already only generated if it's allocated on the heap.

Either I don't understand what you mean or you're wrong ;-) TypeInfo is
generated at declaration time. At that point you can't even know if
a struct will be allocated on the heap at some point. Maybe you're
talking about closures? It is true that _GC_ heap allocation requires
TypeInfo but that's usually considered a bug.

> I suspect
> though that I'm probably just too tired right now to understand the
> intricacies of the topic.

On Friday, 16 January 2015 at 18:37:28 UTC, Johannes Pfau wrote:
> Am Thu, 15 Jan 2015 23:08:57 -0600
> schrieb "Orvid King via D.gnu" <d.gnu@puremagic.com>:
>
> TypeInfo is generated at declaration time. At that point you
> can't even know if a struct will be allocated on the heap at
> some point.

I was wondering... Would it be possible to make selective TypeInfo ?
-Eg. Only add TypeInfo for those things that really need it.
If that's possible, then I think the overhead could be decreased dramatically.

Another way it could perhaps be reduced, would be to change strings into pointers or identifiers. This popped into my mind, because it appears that TypeInfo is zero-terminated C-strings anyway. If those exist in a read-only memory space, then comparing them using strcmp seems quite extraneous; just compare the pointer and put some other data there instead; or make a 32-bit uniqueID (perhaps even a 16-bit UID).

On Thursday, 30 April 2015 at 14:27:17 UTC, Jens Bauer wrote:
> {snip} or make a 32-bit uniqueID (perhaps even a 16-bit UID).

Note: The most frequently used typeinfo should have the lowest ID numbers, because on small devices, loading a small value into a register, will use very little space.

Of course, an 8-bit value can be supported on most systems.

On ARM Cortex-M3 and later, we have several ways of loading small values. One is the 'modified immediate', which is one of the following:
(8-bit value) << (0 ..24)
(8-bit value) * 0x00010001
(8-bit value) * 0x01000100
(8-bit value) * 0x01010101
Then there's a 16-bit load using movw.

Both modified immediate and movw uses 32-bit instructions, but a direct 8-bit value can be loaded using the 16-bit mov.n instruction (also on Cortex-M0).

... My point is that if sorting things like UniqueIDs would result in smaller binaries.