From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8E62C3858C2D; Wed, 14 Sep 2022 09:52:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E62C3858C2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663149156; bh=JpFZV4VMckz5h0rb1Oc/xC50UGGbvkQiXQ0uQZunqSk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=efkyM3y8awXHAs/mkq0VoXtTqYEikU7Z/ID78Ghx1jmqyFOMH/q1fGq1WpWt8LYaA 0y0ltdoEYAckMTHz8gxOwPDn6N60LUU9CMY+6LxLUo82zN7vxGph6EVA49Z+PaTIML DGGz47x/k6Tk7Dl/3MrT02tTp4AhHsbDDpUQVWsI= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106654] [C++23] P1774 - Portable assumptions Date: Wed, 14 Sep 2022 09:52:35 +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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106654 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at gcc dot gnu.org, | |amacleod at redhat dot com, | |jakub at gcc dot gnu.org, | |jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Note, we'll need something similar for OpenMP #pragma omp assume (C/C++/Fortran). I thought we could represent it in the IL as: if (.IFN_ASSUME ()) { if (!cond) __builtin_unreachable (); } where .IFN_ASSUME would eventually be folded into false. We'd need to teach the ranger etc. to take advantage of the bbs guarded by .IFN_ASSUME () as if the condition would be true, the inliner to try to discover SESE regions guarded by that condition and ignore them for size estimation purposes and perhaps have somewhat higher code growth limits into those regions. Richi doesn't like that. Another possibility is to represent these as: .IFN_ASSUME (outlined_fun, args...); where the cond expression would be outlined into an artificial function. Ranger and other optimization passes then could try to evaluate the body of outlined_fun with the assumption that the function returns true (if it retu= rns false, then it is UB). We'd never emit the artificial outlined functions i= nto assembly nor debug info, but would inline into them and try to optimize them after IPA. Would be nice to have callgraph order their post IPA opts before functions that .IFN_ASSUME reference them. Either the outlined functions could be created in the FEs (e.g. for C++ we could perhaps partly use code that we use for lambda capture discoveries), = but the disadvantage would be that we'd need to do it 3 times. So another option would be some new GENERIC/GIMPLE statement kind used for these and lower it only at say gimple lowering time (we have a precedent of creating outlined functions at ompexp time for OpenMP expansion). Thoughts on this? Aldy/Andrew, do you think it is something the ranger cou= ld handle?=