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


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |


--- Comment #10 from Kenji Hara <k.hara.pg@gmail.com> 2012-05-05 00:42:06 PDT ---
Pull #375 was not sufficient, so removed 'patch' keyword.

-- 
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=2356


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |malteskarupke@web.de


--- Comment #11 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-14 11:36:34 PDT ---
*** Issue 8820 has been marked as a duplicate of this issue. ***

-- 
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=2356


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siegelords_abode@yahoo.com


--- Comment #12 from yebblies <yebblies@gmail.com> 2012-10-29 05:14:56 EST ---
*** Issue 8903 has been marked as a duplicate of this issue. ***

-- 
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=2356


Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg@gmail.com


--- Comment #13 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2012-10-30 17:17:29 MSK ---
Workaround for those who like "a, b, c" initialization but need more performance (not: it still calls `_d_arraycopy`):

---
T[n] makeStaticArray(T, size_t n)(T[n] data...)
// { return data; }
{ T[n] res; res = data; return res; } // Issue 8914 workaround

void setStaticArray(T, size_t n)(ref T[n] array, T[n] data...)
{ array = data; }

void main()
{
    auto x = makeStaticArray(1, 2, 3);
    static assert(is(typeof(x) == int[3]));
    assert(x == [1, 2, 3]);

    int[3] y;
    y.setStaticArray(1, 2, 3);
    assert(y == [1, 2, 3]);
}
---

-- 
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=2356


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #14 from Kenji Hara <k.hara.pg@gmail.com> 2013-04-10 10:31:22 PDT ---
New D2 fix: https://github.com/D-Programming-Language/dmd/pull/1883

-- 
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=2356



--- Comment #15 from bearophile_hugs@eml.cc 2013-04-10 19:20:51 PDT ---
(In reply to comment #14)
> New D2 fix: https://github.com/D-Programming-Language/dmd/pull/1883

From the pull request (dmd -O -inline -g test  after):


c:\d\test.d:18     int[3] y = [n, n, n];
004020aa: 6a03                    push 0x3
004020ac: 6a05                    push 0x5
004020ae: 8d4c241c                lea ecx, [esp+0x1c]
004020b2: 51                      push ecx
004020b3: e880020000              call 0x402338 __memset32

Isn't calling memset for just 3 integers slower than inlining their assignments? I suggest to not call memset if the number of bytes to be copied is so small (I think LDC is already doing similar optimizations). Maybe a benchmark is also useful here.


c:\d\test.d:20     S[3] z = [s2, s2, s2];
004020b8: 8d542418                lea edx, [esp+0x18]
004020bc: 52                      push edx
004020bd: 8d442430                lea eax, [esp+0x30]
004020c1: e86affffff              call 0x402030 test.S.__cpctor c:\d\test.d:3
004020c6: 8d5c2418                lea ebx, [esp+0x18]
004020ca: 53                      push ebx
004020cb: 8d442434                lea eax, [esp+0x34]
004020cf: e85cffffff              call 0x402030 test.S.__cpctor c:\d\test.d:3
004020d4: 53                      push ebx
004020d5: 8d442438                lea eax, [esp+0x38]
004020d9: e852ffffff              call 0x402030 test.S.__cpctor c:\d\test.d:3
004020de: 83c40c                  add esp, 0xc
004020e1: 31c0                    xor eax, eax

If the s2 variable already contains the struct, then what's the purpose of those calls to 0x402030?


In the "before" there are no calls to struct constructors:

c:\d\test.d:20     S[3] z = [s2, s2, s2];
00403913: 8d542474                lea edx, [esp+0x74]
00403917: b960014200              mov ecx, 0x420160
0040391c: 52                      push edx
0040391d: 6a03                    push 0x3
0040391f: 6a03                    push 0x3
00403921: 51                      push ecx
00403922: e8fd0a0000              call 0x404424 __d_arrayliteralTX
00403927: 83c408                  add esp, 0x8
0040392a: 8d542470                lea edx, [esp+0x70]
0040392e: 52                      push edx
0040392f: 89c6                    mov esi, eax

-- 
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=2356



--- Comment #16 from Kenji Hara <k.hara.pg@gmail.com> 2013-04-10 19:34:08 PDT ---
(In reply to comment #15)
> (In reply to comment #14)
> > New D2 fix: https://github.com/D-Programming-Language/dmd/pull/1883
> 
> From the pull request (dmd -O -inline -g test  after):
> 
> 
> c:\d\test.d:18     int[3] y = [n, n, n];
> 004020aa: 6a03                    push 0x3
> 004020ac: 6a05                    push 0x5
> 004020ae: 8d4c241c                lea ecx, [esp+0x1c]
> 004020b2: 51                      push ecx
> 004020b3: e880020000              call 0x402338 __memset32
> 
> Isn't calling memset for just 3 integers slower than inlining their assignments? I suggest to not call memset if the number of bytes to be copied is so small (I think LDC is already doing similar optimizations). Maybe a benchmark is also useful here.

It is lowered to:
  int[3] y = void;
  y[] = n;

And currently dmd uses memset for `y[] = n;`. It is another optimization issue.

> c:\d\test.d:20     S[3] z = [s2, s2, s2];
> 004020b8: 8d542418                lea edx, [esp+0x18]
> 004020bc: 52                      push edx
> 004020bd: 8d442430                lea eax, [esp+0x30]
> 004020c1: e86affffff              call 0x402030 test.S.__cpctor c:\d\test.d:3
> 004020c6: 8d5c2418                lea ebx, [esp+0x18]
> 004020ca: 53                      push ebx
> 004020cb: 8d442434                lea eax, [esp+0x34]
> 004020cf: e85cffffff              call 0x402030 test.S.__cpctor c:\d\test.d:3
> 004020d4: 53                      push ebx
> 004020d5: 8d442438                lea eax, [esp+0x38]
> 004020d9: e852ffffff              call 0x402030 test.S.__cpctor c:\d\test.d:3
> 004020de: 83c40c                  add esp, 0xc
> 004020e1: 31c0                    xor eax, eax
> 
> If the s2 variable already contains the struct, then what's the purpose of those calls to 0x402030?
>
>
> In the "before" there are no calls to struct constructors:
> 
> c:\d\test.d:20     S[3] z = [s2, s2, s2];
> 00403913: 8d542474                lea edx, [esp+0x74]
> 00403917: b960014200              mov ecx, 0x420160
> 0040391c: 52                      push edx
> 0040391d: 6a03                    push 0x3
> 0040391f: 6a03                    push 0x3
> 00403921: 51                      push ecx
> 00403922: e8fd0a0000              call 0x404424 __d_arrayliteralTX
> 00403927: 83c408                  add esp, 0x8
> 0040392a: 8d542470                lea edx, [esp+0x70]
> 0040392e: 52                      push edx
> 0040392f: 89c6                    mov esi, eax

Before, cpctor(==postblit) calls are done in __d_arrayliteralTX, so they are hidden. Now they are directly called on the stack memory z[0..3].

-- 
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=2356



--- Comment #17 from bearophile_hugs@eml.cc 2013-04-10 19:44:37 PDT ---
(In reply to comment #16)

> It is lowered to:
>   int[3] y = void;
>   y[] = n;
> 
> And currently dmd uses memset for `y[] = n;`. It is another optimization issue.

OK.


> Before, cpctor(==postblit) calls are done in __d_arrayliteralTX, so they are hidden. Now they are directly called on the stack memory z[0..3].

Sorry I have missed it was the postblit, thank you.

-- 
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=2356



--- Comment #18 from github-bugzilla@puremagic.com 2013-04-11 01:36:48 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/8cd5f790a78e7514e46618d0325e92cbd6e00e48
fix Issue 2356 - array literal as non static initializer generates horribly
inefficient code.

https://github.com/D-Programming-Language/dmd/commit/d4b20baee7a1c9ee8a9271724feb5d1031e773d4 Merge pull request #1883 from 9rnsr/fix2356

Issue 2356 - array literal as non static initializer generates horribly inefficient code.

-- 
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=2356



--- Comment #19 from bearophile_hugs@eml.cc 2013-04-11 05:26:29 PDT ---
The patch seems to work. With it I have removed five optimizations from my code. Very good.

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