http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #1 from Iain Buclaw <ibuclaw@gdcproject.org> ---
FYI, the backend does *almost* the right thing.


        .globl  _D4test6Buffer6__initZ
        .section        .rodata
        .align 64
        .type   _D4test6Buffer6__initZ, @object
        .size   _D4test6Buffer6__initZ, 65536
_D4test6Buffer6__initZ:
        .zero   65536


It is able to correctly recognise that the initialiser is all zeros, and reduces it to .zero 65536.  Unfortunately, because there *is* an initialiser in the first place means that it puts it in .section .rodata, instead of optimising for size and putting it in .bss

What we should be doing is checking if initializer_zerop, then undoing our work.

This has a run-time cost (it would be nice to have a test for all zeros before building and discarding trees) but for the size reduction, it would be worth it.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> ---
https://github.com/D-Programming-GDC/GDC/commit/0fcf8babc0d0af85a9a04aaa23b5856237fbdb9f

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Before:
52976    libgphobos2.a
5980    libgdruntime.a

After:
52824    libgphobos2.a
5976    libgdruntime.a

I guess this means that phobos doesn't have many 0-inited symbols. ;)

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
                 CC|                            |johannespfau@gmail.com
         Resolution|FIXED                       |---

--- Comment #4 from Johannes Pfau <johannespfau@gmail.com> ---
Timo Sintonen noted that this is actually contra-productive at least on
embedded systems. .bss is read-write storage whereas .rodata can be in readonly
storage.
http://forum.dlang.org/post/nadodelkzuwtrnquoove@forum.dlang.org

I wonder whether the reason you don't see a difference in phobos is a string pooling optimization: I'd expect a clever linker to combine all .zero blocks in .rodata into one block with the size of the largest single block, then use 'slices' to that block.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #5 from safety0ff <safety0ff.bugz@gmail.com> ---
Context of this report: it was filed because GDC was failing a dmd test (I
can't remember which now.)

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #6 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to safety0ff from comment #5)
> Context of this report: it was filed because GDC was failing a dmd test (I
> can't remember which now.)

It wasn't failing the test per say.  The test in DMD requires a post-script be ran, something that does not happen for GDC testsuite.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #7 from Johannes Pfau <johannespfau@gmail.com> ---
I'm doing some experiments with D on microcontrollers lately (AVR 8 bit
hello-world(blinking LED) is working: https://github.com/jpf91/GDC/tree/microD
) and I came across this again.

This bugfix leads to the strange situation that zero initializers are a performance penalty on these systems as RW memory is scarce, but intilizers with one member not set to zero are put into .rodata and are therefore a better option.

GCC puts all zero initialzed objects into rodata as well:
------------------------------------------------------------
struct Test
{
    int a;
    int b;
};

const struct Test tb = {0,0};
------------------------------------------------------------
    .globl    tb
    .section    .rodata
    .align 4
    .type    tb, @object
    .size    tb, 8
tb:
    .zero    8
------------------------------------------------------------


So are there any objections against reverting this commit?

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #8 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I have no problems, but maybe we should make a switch for those who want smaller binaries over speed?

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #9 from Johannes Pfau <johannespfau@gmail.com> ---
Sure. Should the default still be rodata? Rodata is also used for normal immutable x = Struct(0,0,0) style variables, so that make make sense.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=139

--- Comment #10 from Johannes Pfau <johannespfau@gmail.com> ---
Reverting this change exposes a test failure in phobos. However every seemingly unrelated change hides the error. gcc-4.9 works fine. So I wonder whether this is actually a bug in the GCC-5 snapshot?

Here's the reduced test case:
----------------
import core.stdc.string;

void test()
{
    struct S { @disable this();}
    S s = void;
    emplaceInitializer(&s);
}

T* emplaceInitializer(T)(T* chunk)
{
    static immutable init = T.init;
    memcpy(chunk, &init, T.sizeof);
    return chunk;
}
----------------
gdc conv.d -c

(sorry, forgot to change language)
----------------
conv.d: In Funktion »emplaceInitializer«:
conv.d:11: Fehler: nicht-triviale Umwandlung bei Zuweisung
ulong
void *
MEM[(unsigned char * {ref-all})chunk] = D.2533;
conv.d:11: interner Compiler-Fehler: verify_gimple gescheitert
0xb2dc8f verify_gimple_in_seq(gimple_statement_base*)
    ../../gcc-5-20140831/gcc/tree-cfg.c:4672
0x930759 gimplify_body(tree_node*, bool)
    ../../gcc-5-20140831/gcc/gimplify.c:8847
0x930b16 gimplify_function_tree(tree_node*)
    ../../gcc-5-20140831/gcc/gimplify.c:8932
0x7a94b7 cgraph_node::analyze()
    ../../gcc-5-20140831/gcc/cgraphunit.c:612
0x7abdad analyze_functions
    ../../gcc-5-20140831/gcc/cgraphunit.c:988
0x7ac515 symbol_table::finalize_compilation_unit()
    ../../gcc-5-20140831/gcc/cgraphunit.c:2277
0x6f487e d_finish_compilation(tree_node**, int)
    ../../gcc-5-20140831/gcc/d/d-objfile.cc:1947
----------------

----------------
{
  void * D.2533;
  struct S * D.2534;

  D.2533 = {};
  MEM[(unsigned char * {ref-all})chunk] = D.2533;
  D.2534 = chunk;
  return D.2534;
}
----------------

-- 
You are receiving this mail because:
You are watching all bug changes.