April 29, 2023 [Issue 23868] New: Compiler-generated opAssign has very high stack frame usage | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23868 Issue ID: 23868 Summary: Compiler-generated opAssign has very high stack frame usage Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nobody@puremagic.com Reporter: johanengelen@weka.io Testcase: ``` struct S { int[100] arr; ~this() {} } S s; ``` This gives AST (https://d.godbolt.org/z/KKzYnPjah): ``` { int[100] arr; ~this() { } alias __xdtor = ~this() { } ; ref @system S opAssign(S p) return { (S __swap2 = void;) , __swap2 = this , (this = p , __swap2.~this()); return this; } } ``` The local `__swap2` variable in the compiler-generated opAssign() results in very high stack frame usage for large structs. I believe this implemention of opAssign would solve the problem, as I am 99% sure that the semantic difference (dtor call before the assignment) is allowed by the spec: ``` ref @system S opAssign(S p) return { this.S.~this(); this = p; return this; } ``` Workaround is to disable the generation of opAssign: `@disable ref typeof(this) opAssign(typeof(this) p);`. -- |
Copyright © 1999-2021 by the D Language Foundation