From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ECB7F3858D20; Mon, 15 Jan 2024 13:47:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECB7F3858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1705326436; bh=YD9RM12itlWoiSXaTa9tCxxJkUDYePlbGdLr8NdJxvE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IdHnIMkkR/lEc7YtS0LEL5AKnj75DDwjqaTr53ksc73HBk5YGxkh5jFk/41FJ7Bar kDPjii8dxIY0uzYQv4dhGop0dFqsSc4BEoEKzmvmBEH3V0tqHOxecQlHG7eMWcXsc7 wZONYXVy7hwq3d7B6ltmX9sp33ieuIc+Sa0/F/vQ= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1 Date: Mon, 15 Jan 2024 13:47:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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: 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=3D113372 --- Comment #13 from rguenther at suse dot de --- On Mon, 15 Jan 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113372 >=20 > --- Comment #12 from Jakub Jelinek --- > (In reply to Richard Biener from comment #11) > > So the key would be to make the object live again after a CLOBBER when = such > > address SSA name is used (but before any other explicit mention appears= )? > >=20 > > The current algorithm relies on explitic mentions appearing, one origin= al > > idea was to turn those explicit mentions (or BLOCK starts) into > > start-of-live CLOBBERs, but even that was shown to be not enough. > >=20 > > But yes, if we want to try to mitigate the problems somewhat without > > doing a full solution then possibly even just looking at SSA defs > > when POINTER_TYPE and the def is an ADDR_EXPR might work (in the > > visit_* callbacks of the walk_stmt_load_store_addr_ops), no propagation > > needed at all (basically just undo CSE virtually here for the simple > > cases). >=20 > It couldn't be limited to just POINTER_TYPE, because it mostly is actually > pointer-sized unsigned integer from IVOPTs, but yes, even without full > propagation I think all the testcases I've mentioned could be solved by j= ust > doing the short walks in PHI arguments or other SSA_NAME uses (only PR111= 422 > needs the latter). > For this PR, we'd need to visit for ivtmp.40_3 uses in PHI args the def-s= tmt: > ivtmp.40_3 =3D (unsigned long) &MEM [(void *)&biti= nt.6 + > 8B]; > for PR90348 ivtmp.32_28's def-stmt: > ivtmp.32_28 =3D (unsigned long) ∈ > for PR110115 ivtmp.27_2's def-stmt: > ivtmp.27_2 =3D (unsigned long) &h; > fpr PR111422 _44's def-stmt: > _44 =3D &g + _43; > So, if you think it is ok to use just a small hack rather than full propa= gation > (which could even handle const/pure calls perhaps if they return pointer = or > pointer-sized integer), I can implement that too. Even the full propagat= ion > wouldn't handle everything of course, but could handle more than the smal= l hack > (which would need to be limited to just say 4 def-stmts and wouldn't try = to > look through PHIs). I think we don't expect arbitrary complex obfuscation. We do have RPO order computed so propagation cost would be mostly a bunch of bitmaps (possibly one per SSA name), but with PHIs we'd need to iterate. I wonder if this could be done along the propagation add_scope_conflicts does itself - can we do this within add_scope_conflicts_1 when for_conflict =3D=3D false? I'd think so (though whether a change occured is more difficult to track?). What would you then consider a mention that's not explicit? Any that we couldn't further propagate to its uses? Thus also mem =3D _1; with _1 having the address of some local?=