www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 12313] New: Unneeded stack temporaries created by tuple foreach

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313

           Summary: Unneeded stack temporaries created by tuple foreach
           Product: D
           Version: D1 & D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: public dicebot.lv


--- Comment #0 from Dicebot <public dicebot.lv> 2014-03-07 07:23:09 PST ---
This issue is present for both D1 and D2 but seems to be partially compensated
by better optimizer in dmd2.

Current foreach implementation (ForeachStatement::semantic) creates a local
stack temporary for every element of expression tuple foreach it iterates over:

=== test.d ===
struct A
{
    int a, b, c;
}

void main()
{
    A a;
    // this empty loop creates variables as copies of every member of a
    foreach (var; a.tupleof)
    {}
}
======

There are two issues with it:

1) stack space can easily go out of control with algorithms on long tuples (it
has just his us in Sociomantic)

2) it prevents one from writing to `var` and forces to use ugly index idiom
instead: `foreach (index, var; a.tupleof) { a.tupleof[index] = 42; }`

Can't tell possible impact of removing those temporaries right now, needs some
experiments.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 07 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313



--- Comment #1 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-07
17:24:14 EET ---
Have you tried using "ref"? IIRC that worked for my code.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 07 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313



--- Comment #2 from Dicebot <public dicebot.lv> 2014-03-07 07:48:35 PST ---
Does not work for D1: "Error: no storage class for value var"

It does not also make any sense from language semantics point of view as
a.tupleof is effectively tuple of variable aliases. And there is no such thing
as `ref alias`.

Sounds more like a hack to fix another hack.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 07 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313


Vladimir Panteleev <thecybershadow gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow gmail.com


--- Comment #3 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-07
17:54:23 EET ---
(In reply to comment #2)
 It does not also make any sense from language semantics point of view as
 a.tupleof is effectively tuple of variable aliases. And there is no such thing
 as `ref alias`.
 
 Sounds more like a hack to fix another hack.

I see it more like the foreach body being like a function (whose body is implicitly inlined). In this context, "ref" works out fine. Since .tupleof only enumerates fields, and not functions, each member can be mapped to a concrete value (and thus can work with "ref"). -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 07 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313



--- Comment #4 from Dicebot <public dicebot.lv> 2014-03-07 07:56:56 PST ---
foreach != tuple foreach

latter is more like template declaration that gets instantiated for every tuple
element as an argument

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 07 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313



--- Comment #5 from Kenji Hara <k.hara.pg gmail.com> 2014-03-07 22:48:17 PST ---
(In reply to comment #4)
 foreach != tuple foreach
 
 latter is more like template declaration that gets instantiated for every tuple
 element as an argument

If you want to iterate the elements of the container (array, range, tuple, etc) without copying, use 'ref'. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 07 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313



--- Comment #6 from Dicebot <public dicebot.lv> 2014-03-08 03:45:10 PST ---
D1 does not have ref foreach.
tuple is not a container.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 08 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313



--- Comment #7 from Vladimir Panteleev <thecybershadow gmail.com> 2014-03-08
13:58:48 EET ---
Since D2 has a trivial workaround, can we agree that this is a D1-only bug?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 08 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=12313



--- Comment #8 from Dicebot <public dicebot.lv> 2014-03-08 03:59:53 PST ---
I'd say it is D1 bug and D2 enhancement request ;)
But for practical concerns it can be considered D1-only, no problem.

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