From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 386C63858411; Mon, 25 Oct 2021 09:55:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 386C63858411 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize Date: Mon, 25 Oct 2021 09:55:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 11.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: jakub at gcc dot gnu.org 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: Mon, 25 Oct 2021 09:55:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102876 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- (In reply to Jason Merrill from comment #6) > It's not clear to me that this optimization should use the constexpr > machinery; as I commented on bug 4131. If optimization turns the > initialization of a static variable into a simple matter of storing a > constant value, it should go one step further and turn that constant value > into a constant initializer. I guess that would be possible, a targetted optimization pass for __static_initialization_and_destruction_* and _GLOBAL__sub_I_* functions (or just the latter). It would need to be done after IPA and after various optimization passes afterwards so that the functions can be optimized enough, on the other side with some further optimization passes still to go, so that when we optimize away all the stores something can cleanup the function and some further optimization can kick in and kill empty _GLOBAL__sub_I_* functions altogeth= er. For each dynamically initialized var it would probably need to try to build updated DECL_INITIAL CONSTRUCTOR (starting from the one the var has if any), maybe punt whenever some particular leaf field is initialized multiple time= s, certainly punt if initialized by non-constant, maybe punt if a union has mo= re than one field initialized, etc. But I'm worried about larger TUs where not all dynamic initialization can be optimized into constants. E.g. if there remain any function calls where the alias analysis could think they can read or modify the vars or their subobj= ects etc., we'd need to punt. Perhaps we could when generating these functions wrap the dynamic initialization of each var by calls into some new IFN that would take addre= ss of the variable and for alias analysis say it reads it but doesn't modify a= nd doesn't escape the address. In C++ one can't read the var in other initializers until it has been constructed, right? So the opening IFN would stand as the first stmt that may read or write the variable and similarly everything after the closing IFN would be considered unrelated code to that. Not sure if we can reliably detect that the variable was declared read-only= and isn't TREE_READONLY only because it has dynamic initialization (and that it= is safe to optimize it into a .rodata var). And, probably it would be best if we could arrange for post-IPA to handle t= hese global initialization functions as early as possible so that we don't need = to give up because the vars were already emitted into assembly.=