On 11/22/22 09:25, Richard Biener wrote:
On Tue, Nov 22, 2022 at 9:24 AM Richard Biener
<richard.guent...@gmail.com> wrote:
On Mon, Nov 21, 2022 at 5:49 PM Jeff Law <jeffreya...@gmail.com> wrote:
On 11/21/22 09:35, Aldy Hernandez via Gcc-patches wrote:
I've been playing around with removing the legacy VRP code for the
next release. It's a layered onion to get this right, but the first
bit is pretty straightforward and may be useful for this release.
Basically, it entails removing the old VRP pass itself, along with
value_range_equiv which have no producers left. The current users of
value_range_equiv don't put anything in the equivalence bitmaps, so
they're basically behaving like plain value_range.
I removed as much as possible without having to change any behavior,
and this is what I came up with. Is this something that would be
useful for this release? Would it help release managers have less
unused cruft in the tree?
Neither Andrew nor I have any strong feelings here. We don't foresee
the legacy code changing at all in the offseason, so we can just
accumulate these patches in local trees.
I'd lean towards removal after gcc-13 releases.
I think removing the ability to switch to the old implementation easens
maintainance so I'd prefer to have this before the gcc-13 release.
So please go ahead.
Btw, ASSERT_EXPR should also go away with this, no?
Ah yes, for everything except ipa-*.* which uses it internally (and sets
it in its internal structures):
- ASSERT_EXPR means that only the value in operand is allowed to
pass
through (without any change), for all other values the result is
unknown.
I can remove all other uses, including any externally visible documentation.
Thanks.
Aldy
