Don't emit init symbol for zero-initialized structs

[kinke]

No description provided.

[JohanEngelen]

Last time I looked at this, I think we came to the conclusion that the symbol always needs to be emitted because of people referencing it, but becaue .init is not an lvalue I don't know how to create a reference to the init symbol (not whether that'd be invalid code or not)

[kinke]

Ah yeah, that rings a bell now, I completely forgot about it.

but becaue .init is not an lvalue I don't know how to create a reference to the init symbol

Me neither, it's not referenced by the TypeInfo either, so I can only think of referencing it manually by name (pragma mangle tricks etc.).

[kinke]

Do we want to risk this (replacing the assert by a fatal codegen error obviously) or should I take a step back, re-emitting the symbols and only avoiding their usage?

[JohanEngelen]

I wish I could test this on Weka's codebase, but there is too much breakage with recent compilers to test this quickly.
I'll see if I can backport this and check linking. Will take me a week or so.

[kinke]

Okay, would be nice; I'll defer the beta then (but please let me know if you don't find any time).

[JohanEngelen]

Done, testing showed no issues. Good to go from my side.

[kinke]

Thx mate.

[EyalIO]

Thanks, @kinke !

I just backported this fix to our compiler, to see its effect on executable size.
I've noticed we stil have very large init symbols for all-zero classes.
Is there a reason this isn't done for classes too?
The vtbl/etc inside classes isn't really copied from the "init" symbol but set by generated assignments, so all we use the "init" for is the fields (which is equivalent to memset).

Anyway, I'm trying my luck at changing classes to skip the init symbols too, and hoping I'm doing it correctly :)

[kinke]

Is there a reason this isn't done for classes too?
The vtbl/etc inside classes isn't really copied from the "init" symbol but set by generated assignments, so all we use the "init" for is the fields (which is equivalent to memset).

It'd be a violation or at least a big dangerous breaking change of the TypeInfo_Class.initializer protocol. After a quick glance, there's _d_newThrowable (-dip1008) which depends on it being complete (compiler doesn't re-init manually afterwards) and would currently simply segfault if the pointer was null, like presumably other places in druntime (and possibly Phobos too).
DtoInitClass() also just sets vptr and monitor manually; e.g., it does depend on interface vptrs being set in the init symbol, which can interleave with base class fields...

[EyalIO]

Oh bummer :-(

Thanks for the input!