digitalmars.D.bugs - [Issue 12313] New: Unneeded stack temporaries created by tuple foreach
- d-bugmail puremagic.com (40/40) Mar 07 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (6/6) Mar 07 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (10/10) Mar 07 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (14/19) Mar 07 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (8/8) Mar 07 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (8/12) Mar 07 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (7/7) Mar 08 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (6/6) Mar 08 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
- d-bugmail puremagic.com (7/7) Mar 08 2014 https://d.puremagic.com/issues/show_bug.cgi?id=12313
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 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
https://d.puremagic.com/issues/show_bug.cgi?id=12313 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
https://d.puremagic.com/issues/show_bug.cgi?id=12313 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
https://d.puremagic.com/issues/show_bug.cgi?id=12313 Vladimir Panteleev <thecybershadow gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thecybershadow gmail.com 17:54:23 EET ---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
https://d.puremagic.com/issues/show_bug.cgi?id=12313 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
https://d.puremagic.com/issues/show_bug.cgi?id=12313foreach != tuple foreach latter is more like template declaration that gets instantiated for every tuple element as an argumentIf 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
https://d.puremagic.com/issues/show_bug.cgi?id=12313 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
https://d.puremagic.com/issues/show_bug.cgi?id=12313 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
https://d.puremagic.com/issues/show_bug.cgi?id=12313 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