http://d.puremagic.com/issues/show_bug.cgi?id=11331

           Summary: Inefficient initialization of struct
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrei@erdani.com


--- Comment #0 from Andrei Alexandrescu <andrei@erdani.com> 2013-10-23 08:54:25 PDT ---
Consider the following stack region:

struct InSituRegion2(size_t size)
{
    // The store will be aligned to realof.align
    union
    {
        private ubyte[size] _store = void;
        real _forAlignmentOnly;
    }
    void* _crt, _end;

    void[] allocate(size_t bytes)
    {
          assert(_crt && _end);
        // round up
        const rounded = (bytes + real.alignof - 1) / real.alignof;
        auto newCrt = _crt + rounded;
        if (newCrt > _end) return null;
        auto result = _crt[0 .. bytes];
        _crt = newCrt;
        return result;
    }
}

size_t fun2(size_t s)
{
    InSituRegion2!(1024 * 64) r;
      r._crt = r._store.ptr;
      r._end = r._store.ptr + r._store.length;
    auto a = cast(uint[]) r.allocate(s);
    return a[s / 2];
}

(The code of fun2 has been written to be complex enough to avoid a few elisions effected by optimizers.)

Disassembly reveals that constructing the struct object entails a memcpy of the object's init over the object memory, even though most of the object is deliberately left uninitialized. This undoes the performance gains of defining and using an encapsulated stack region.

The initialization function should either use multiple memcpy calls or individual word assignments.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11331


Dicebot <public@dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public@dicebot.lv


--- Comment #1 from Dicebot <public@dicebot.lv> 2013-10-23 09:26:14 PDT ---
Erm, isn't it by spec? `void` initializer is targeted for variables, not member fields. Here it just says that relevant `T.init` part can be garbage.

Fixing this issue would imply that there are no more guaranteed deterministic T.init values for all types.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11331



--- Comment #2 from Andrei Alexandrescu <andrei@erdani.com> 2013-10-23 09:53:31 PDT ---
@Dicebot: yah, it's an enhancement. One of the spec as well :o). The .init value can still exist, but the initialization doesn't need to use it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11331



--- Comment #3 from Dicebot <public@dicebot.lv> 2013-10-23 09:55:29 PDT ---
(In reply to comment #2)
> @Dicebot: yah, it's an enhancement. One of the spec as well :o). The .init value can still exist, but the initialization doesn't need to use it.

Well, this sounds like quite an important change - I'd prefer this issue description to tell more about possible implications of that spec change than about generated assembly :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=11331



--- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> 2013-10-23 10:07:14 PDT ---
http://dlang.org/struct.html mentions that "Struct instances that are not instantiated with a constructor are default initialized to their .init value." and mentions that S() is "same as auto b = S.init;"

There is no guarantee about the values of the = void members in S.init, but definitely the spec clarifies that two default-constructed objects will compare equal. So we need to change the spec to only guarantee non-=void fields of default-constructed objects to be equal.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------