From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 25F8C394504F; Sun, 6 Jun 2021 15:30:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25F8C394504F From: "gabravier at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/95405] Unnecessary stores with std::optional Date: Sun, 06 Jun 2021 15:30:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: gabravier at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2021 15:30:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95405 Gabriel Ravier changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gabravier at gmail dot com --- Comment #2 from Gabriel Ravier --- Welp, I've tried to convert this to a simplified form, but I can't seem to = get the same output regardless of how close I get in terms of GIMPLE output. With this code: struct opbeb {}; union opbs { opbeb empty_byte; long value; }; struct opb { opbs payload; bool engaged; }; struct op : public opb { }; struct ob { op payload; }; struct o { ob base; }; o foo(); long bar() { struct o r =3D foo(); if (__builtin_expect_with_probability((*(const ob *)&r).payload.eng= aged !=3D 0, 1, .66)) return (long &)*(long *)&r; else return 0; } I get this final GIMPLE (i.e. -fdump-tree-optimized): ;; Function bar (_Z3barv, funcdef_no=3D9255, decl_uid=3D109154, cgraph_uid= =3D6606, symbol_order=3D6814) Removing basic block 5 long int bar () { struct o r; bool _1; long int _4; long int _7; [local count: 1073741824]: r =3D foo (); _1 =3D MEM[(const struct ob *)&r].payload.D.109140.engaged; if (_1 !=3D 0) goto ; [66.00%] else goto ; [34.00%] [local count: 708669601]: _7 =3D MEM[(long int &)&r]; [local count: 1073741824]: # _4 =3D PHI <_7(3), 0(2)> r =3D{v} {CLOBBER}; return _4; } Which seems to be almost exactly identical to the one I get from the real std::optional: ;; Function bar (_Z3barv, funcdef_no=3D6084, decl_uid=3D49565, cgraph_uid= =3D5869, symbol_order=3D5916) Removing basic block 5 long int bar () { struct optional r; long int _1; bool _4; long int _5; [local count: 1073741824]: r =3D foo (); _4 =3D MEM[(const struct _Optional_base *)&r]._M_payload.D.50442._M_engag= ed; if (_4 !=3D 0) goto ; [66.00%] else goto ; [34.00%] [local count: 708669601]: _5 =3D MEM[(long int &)&r]; [local count: 1073741824]: # _1 =3D PHI <_5(3), 0(2)> r =3D{v} {CLOBBER}; return _1; } Literally the only differences I can see is that variables are declared in a different order, and that some variable names are different. Yet the assembly output for my version optimizes the store to memory away j= ust fine, and the std::optional output still fails to optimize the store to mem= ory. Is the (very minor) difference here this significant or is there something I can't see in the outputted GIMPLE that results in the differences ? I tried= to delve into the RTL, though I failed to really understand what was going on (though I could see significant differences between what I wrote and the original example there). I've also checked the assembly, and as far as I can see, there is no functi= onal difference between what I wrote and the original one, LLVM even produces the exact same assembly for both. I've also tried to rule out the difference in variable declaration placement and naming by rewriting what I wrote into GIMPLE and modifying it to correspond to the original example as well as possible, with this being my = best effort: long int __GIMPLE (ssa,guessed_local(1073741824)) bar () { struct o r; long int _1; bool _4; long int _7; __BB(2,guessed_local(1073741824)): r =3D foo (); _4 =3D __MEM ((const struct ob *)&r).payload.base.engag= ed; if (_4 !=3D _Literal (bool) 0) goto __BB3(guessed(88583700)); else goto __BB4(guessed(45634028)); __BB(3,guessed_local(708669601)): _7 =3D __MEM (&r); goto __BB4(precise(134217728)); __BB(4,guessed_local(1073741824)): _1 =3D __PHI (__BB3: _7, __BB2: 0l); r =3D _Literal (struct o) {}; return _1; } But it still gets optimized well, as expected, unlike the original, which is rather mind boggling to me, unless there really is a bunch of GIMPLE information that isn't part of the outputted form. PS: LLVM optimizes the original example and what I wrote perfectly fine to = the same assembly code.=