[Issue 14758] TypeInfo causes excessive binary bloat

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Mike Franklin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Mike Franklin  ---
I consider this resolved due to https://github.com/dlang/dmd/pull/7799

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #17 from Mike  ---
GDC appears to have solved this problem by wrapping `TypeInfo.name` in a static
variable.  See
https://github.com/D-Programming-GDC/GDC/pull/505#event-1141470083

I tested it on ARM Cortex-M and it works as expected.  Perhaps there's
something there that the other compilers can leverage.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Walter Bright  changed:

   What|Removed |Added

   Keywords||betterC

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #16 from Iain Buclaw  ---
(In reply to Mike from comment #15)
> Just tested this with LDC 1.0.0 (frontend 2.070.2), and the dead code is
> still in the binary.  The DMD generated binary looks good, but the LDC
> binary is still bloated with dead code.  I'm assuming the change made by
> Walter in Comment 9 only affected the DMD backend.
> 
> It appears GDC is still on 2.067, so I haven't tested there, but given my
> results with LDC 1.0.0, I don't expect GDC to be any better.

TypeInfo should be better, however ClassInfo is the last on my list to fix due
to its complexity.

On my side, all generated layouts for types in object.d will eventually all be
moved over to a pick-n-choose way of writing out members.  Meaning if you
remove one member from TypeInfo - size checking has been thrown out the window
- it won't generate any data for it.

Because of ClassInfo being prevalent almost everywhere though, you may not
notice side effects just yet.  And though it's yet to be tested whether there's
any benefit, I'm optimistic. :-)

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #15 from Mike  ---
Just tested this with LDC 1.0.0 (frontend 2.070.2), and the dead code is still
in the binary.  The DMD generated binary looks good, but the LDC binary is
still bloated with dead code.  I'm assuming the change made by Walter in
Comment 9 only affected the DMD backend.

It appears GDC is still on 2.067, so I haven't tested there, but given my
results with LDC 1.0.0, I don't expect GDC to be any better.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #14 from Mike  ---
I've tested this issue with DMD v2.069 and the results look good.  I had to
modify my test code.  For some reason I now have to add additional stubs for
Throwables, but that's a separate issue.  Here's the code to get a build.

// object.d
module object;

alias immutable(char)[] string;

class Object 
{ }

class TypeInfo 
{ 
bool equals(in void* p1, in void* p2) const 
{ 
return p1 == p2; 
}

int compare(in void* p1, in void* p2) const 
{ 
return _xopCmp(p1, p2); 
}
}

class TypeInfo_Class : TypeInfo
{
ubyte[136] ignore;
}

alias TypeInfo_Class ClassInfo;

extern (C) Object _d_newclass(const ClassInfo ci)
{ 
return null;
}

extern(C) void _d_throwc(Object h)
{ }

class Throwable
{ }

class Error : Throwable
{ 
this(string x)
{ }
}

extern(C) void _d_dso_registry(void* data)
{ }

//test.d
module test;

long sys_write(long arg1, in void* arg2, long arg3)
{
long result;

asm
{
mov RAX, 1;
mov RDI, arg1;
mov RSI, arg2;
mov RDX, arg3;
syscall;
}

return result;
}

void write(in string text)
{
sys_write(2, text.ptr, text.length);
}

void write(A...)(in A a)
{
foreach(t; a)
{
write(t);
}
}

final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }

extern(C) void main()
{
write("Hello\n");
}

Compile on 64-bit Linux with ( This method compiles without phobos or druntime
to obtain the smallest possible binary):
dmd -m64 -defaultlib= -debuglib= -conf= -betterC -release object.d test.d
-oftest

Analyze with
objdump -s -j .rodata test

Contents of section .rodata:
 400760 01000200     
 400770 54797065 496e666f 2e657175 616c7320  TypeInfo.equals 
 400780 6973206e 6f742069 6d706c65 6d656e74  is not implement
 400790 65640054 79706549 6e666f2e 636f6d70  ed.TypeInfo.comp
 4007a0 61726520 6973206e 6f742069 6d706c65  are is not imple
 4007b0 6d656e74 65640048 656c6c6f 0a00  mented.Hello

As you can see the situation is MUCH improved, but there are still these
strange messages about TypeInfo.equals and TypeInfo.compare.  I think I'll file
a separate issue for that.

I'm hesitant to close this issue at the moment because the test case to
illustrate the issue uses DMD's backed, which doesn't support my platform (ARM
Cortex-M); I'm not sure if the change just swept the issue under the rug in
DMD's backend or genuinely addressed the problem.  I intend to test if the
changes also improved things for LDC and GDC, and will update this issue with
more information as I get results.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Johannes Pfau johannesp...@gmail.com changed:

   What|Removed |Added

 CC||johannesp...@gmail.com

--- Comment #11 from Johannes Pfau johannesp...@gmail.com ---
 There are very few places where dynamic type info is actually necessary, it's 
  just that they were used by the old C style compiler runtime interface.

Yes, we should probably revisit these cases at some point. I wanted to cleanup
my noRTTI (fno-rtti option for gdc) branch for DMD but I thought we won't merge
big non-DDMD changes for 2.069 so I postponed that.

I think the most important thing really requiring TypeInfo might be class down
casts. I don't see how you can do that without some kind of RTTI. But we could
just use some minimal RTTI for that (As long as we can put a unique pointer for
every class in the vtable any kind of RTTI should work).

There's also some postblit related stuff where I think the compiler could
statically generate the necessary code. It was probably easier to implement it
in druntime using RTTI.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #13 from Mike slavo5...@yahoo.com ---
(In reply to Martin Nowak from comment #10)

 I don't think you can properly use D on a small SoC with TypeInfo or
 ModuleInfo.

Yes, it is seldom needed, but the current toolchain implementation is too
tightly coupled to it, so it's not so easily removed.  See
http://forum.dlang.org/post/nfqgmfvixhgjsvtvm...@forum.dlang.org for a relevant
discussion.

 Please try the -betterC switch, it's supposed to avoid all runtime
 dependencies.

If you look at the example posted in the initial comment of this issue, you
will see that the -betterC switch was used, yet the dead code remains.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #12 from Sobirari Muhomori dfj1es...@sneakemail.com ---
Downcasts can be done the COM way:

void* TypeId(T)=TypeId;

final T toType(T)()
{
  cast(T)toType(TypeId!T); //reinterpret_cast
}

override void* toType(void* typeId)
{
  if(typeId==TypeId!Me)return this;
}

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #10 from Martin Nowak c...@dawg.eu ---
 There have been proposals to add a -nortti flag to the compiler to remove 
 TypeInfo completely, but that would force a compromise on slicing, postblit 
 and other features.  Such compromises are most undesirable.

There are very few places where dynamic type info is actually necessary, it's
just that they were used by the old C style compiler runtime interface.
The remaining places are mostly GC, rt.lifetime, and currently the AA.
I don't think you can properly use D on a small SoC with TypeInfo or
ModuleInfo.
Please try the -betterC switch, it's supposed to avoid all runtime
dependencies.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #7 from Dmitry Olshansky dmitry.o...@gmail.com ---
(In reply to Mike from comment #6)
 (In reply to Sobirari Muhomori from comment #5)
  And compile with -O2 or -Os
 
 Doesn't work.  See
 http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org

Yes, but try without classes.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #2 from Mike slavo5...@yahoo.com ---
(In reply to Dmitry Olshansky from comment #1)

 I'd just go for structs + template mixins for inheritance. It's not like you
 do any of virtual calls/typeinfo/object factory/whatever.
 
 mixin template Register(blah...){ }
 
 struct Peripheral{
 
 mixin Register!(x,y,z,...);
 mixin Register!(q,w,e,...);
 
 }
 
 Makes any sesne?

Yes, it makes sense, but it is not my preference, and is beside the point of
this issue.  Furthermore, with your suggestions, you will still have a new type
for each peripheral, and therefore unwanted TypeInfo bloat for each and every
one of those peripherals.

The compiler/linker should generate efficient code using my pattern, and I
shouldn't have to compromise.  Nor should I have to add stubs for runtime
features that have no hope of every being used.  Rust does a good job with
this, and I don't see why I should have to lower my expectations for D.

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #3 from Sobirari Muhomori dfj1es...@sneakemail.com ---
I have an impression that LDC doesn't generate TypeInfo for structs for me
(because when it does, linking fails), if I don't use array comparisons and
disable opEquals. The Rust argument is valid though :)

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #8 from Sobirari Muhomori dfj1es...@sneakemail.com ---
I mean -O0 leaves all junk intact, so at least with LDC -Os is required for
successful linking (or maybe it was required before I wrote needed druntime
functions? will see). I didn't try to use classes yet (wonder what I would do
when I need polymorphism).

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

   Keywords||performance
 CC||bugzi...@digitalmars.com

--- Comment #9 from Walter Bright bugzi...@digitalmars.com ---
Partial fix: https://github.com/D-Programming-Language/dmd/pull/4912

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #5 from Sobirari Muhomori dfj1es...@sneakemail.com ---
And compile with -O2 or -Os

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Dmitry Olshansky dmitry.o...@gmail.com changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #1 from Dmitry Olshansky dmitry.o...@gmail.com ---
 I have modeled these statically with D's fantastic modelling features to 
 produce an object-oriented, easily-navigable hierarchy of the hardware memory 
 map (example: 
 https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/gpio.d).
   It is an excellent model that generates fast code and plays very well with 
 tooling.  The only problem is the TypeInfo bloat.


I'd just go for structs + template mixins for inheritance. It's not like you do
any of virtual calls/typeinfo/object factory/whatever.

mixin template Register(blah...){ }

struct Peripheral{

mixin Register!(x,y,z,...);
mixin Register!(q,w,e,...);

}

Makes any sesne?

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

--- Comment #6 from Mike slavo5...@yahoo.com ---
(In reply to Sobirari Muhomori from comment #5)
 And compile with -O2 or -Os

Doesn't work.  See
http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org

--

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14758

Mike slavo5...@yahoo.com changed:

   What|Removed |Added

   Keywords||bare-metal

--