From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EFF36385829A; Tue, 12 Mar 2024 20:41:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFF36385829A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1710276071; bh=S7r/RRFcNWF1Vwv2uekGC0rJu7TptfsGPy+0ZlRA2q8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HLCLxJIp6dB/aKxudkrvvtAInKsRt92W3nGDYo9JZmC9ddAYVfGPDibWuj6HxnTix TffcrlkfPOdXPiKDdufu5eoOxPtrThdGFZ+FbNxaeRDSklQ7S11BCiEwdhYrVhRlNb N/RkVMhwPLRZx7OCEiALl+T4fz37/fW+aHQ4Ann8= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193 Date: Tue, 12 Mar 2024 20:41:10 +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: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 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=3D114151 --- Comment #21 from Andrew Macleod --- (In reply to Richard Biener from comment #19) >=20 > While ranger has a range_on_exit API this doesn't work on GENERIC express= ions > as far as I can see but only SSA names but I guess that could be "fixed" > given range_on_exit also looks at the last stmt and eventually defers to > range_of_expr (or range_on_entry), but possibly get_tree_range needs > variants for on_entry/on_exit (it doesn't seem to use it's 'stmt' context > very consistently, notably not for SSA_NAMEs ...). That would appear to be an oversight. That API has not been used very much = for arbitrary generic trees. I think the original reason support for tree expressions was added was a "try this" for some other PR. It was simple to = do so we lef tit in, but it never got any real traction. At least as far as I= can recall :-) Currently, I think mosrt, if not all, uses of get_tree_range() are either !gimple_ssa_range_p() (commonly constants or unsupported types) or ssa_name= s on abnormal edges.=20 For abnormal edges, we ought to be getting the global range directly these = days instad of calling that routine. Then in get_tree_range (), we ought to be calling range_of_expr for SSA_NAMES with the provided context. I'll poke at that too. The support for general tree expressions changed the original int= ent of the function, and it should be adjusted.=20 As for the on-exit/on-entry bits... we haven't had a need for entry/exit outside of ranger in the past. I had toyed with exporting those routines a= nd making them a part of the official API for value-query, but hadn't run acro= ss the need as yet. Let me think about that for a minute. It can certainly be done. I guess we really only need an on-entry and on-exit version of range_of_expr to do everything. So if we end up with something like:=20=20 range_of_expr (r, expr, stmt) range_of_expr_on_entry (r, expr, bb) range_of_expr_on_exit (r, expr, bb) And have that all work with general trees expressions.. That would solve mu= ch of this for you? >=20 > Interestingly enough we somehow still need the >=20 >=20 > hunk of Andrews patch to do it :/ >=20 That probably means there is another call somewhere in the chain with no context. However, I will say that functionality is more important than it seems. Should have been there from the start :-P.=