Thread overview
[Issue 14451] static-foreach uses huge stack for no reason
Apr 16, 2015
Tomer Filiba
Apr 16, 2015
yebblies
Apr 16, 2015
Tomer Filiba
Apr 17, 2015
yebblies
Aug 15, 2016
Ali Cehreli
Dec 17, 2022
Iain Buclaw
April 16, 2015
https://issues.dlang.org/show_bug.cgi?id=14451

Tomer Filiba <tomerfiliba@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tomerfiliba@gmail.com

--
April 16, 2015
https://issues.dlang.org/show_bug.cgi?id=14451

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--- Comment #1 from yebblies <yebblies@gmail.com> ---
Scoped properly or not, each variable is going to take up stack space.  Space for all variables is always allocated at the start of the function, inner scopes just control when destructors are run.  I can't really see this changing.

This could be fixed by allowing the backend to re-use stack space for variables whose lifetimes do not overlap.

--
April 16, 2015
https://issues.dlang.org/show_bug.cgi?id=14451

--- Comment #2 from Tomer Filiba <tomerfiliba@gmail.com> ---
you are correct:

===================
void foo() {
    {
        ulong[32] x;
        writeln(x.ptr);
    }
    {
        ulong[32] x;
        writeln(x.ptr);
    }
    {
        ulong[32] x;
        writeln(x.ptr);
    }
    {
        ulong[32] x;
        writeln(x.ptr);
    }
    {
        ulong[32] x;
        writeln(x.ptr);
    }
}
===================

yields

7FFFB9A1E8A0
7FFFB9A1E9A0
7FFFB9A1EAA0
7FFFB9A1EBA0
7FFFB9A1ECA0

it seems a pity to waste so much stack... having the backend reuse dead parts of the stack is crucial for embedded applications or heavily-parallel ones that rely to thousands of small stacks.

of course it could be re-written

====================
void foo() {
    (){
        ulong[32] x;
        writeln(x.ptr);
    }();
    (){
        ulong[32] x;
        writeln(x.ptr);
    }();
    (){
        ulong[32] x;
        writeln(x.ptr);
    }();
    (){
        ulong[32] x;
        writeln(x.ptr);
    }();
    (){
        ulong[32] x;
        writeln(x.ptr);
    }();
}
===================

which then works just fine:

7FFF4101C4A0
7FFF4101C4A0
7FFF4101C4A0
7FFF4101C4A0
7FFF4101C4A0

couldn't inner-scopes be rewritten like that, only making sure the lambda is fully-scoped so that external variables will be heap-allocated

--
April 17, 2015
https://issues.dlang.org/show_bug.cgi?id=14451

--- Comment #3 from yebblies <yebblies@gmail.com> ---
(In reply to Tomer Filiba from comment #2)
> couldn't inner-scopes be rewritten like that, only making sure the lambda is fully-scoped so that external variables will be heap-allocated

That is automatic outlining, and while possible, is something we're unlikely to see any time soon in dmd.

--
August 15, 2016
https://issues.dlang.org/show_bug.cgi?id=14451

Ali Cehreli <acehreli@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |industry
                 CC|                            |acehreli@yahoo.com

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=14451

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--
December 13
https://issues.dlang.org/show_bug.cgi?id=14451

--- Comment #4 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/18976

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--