On Fri, Mar 28, 2025 at 08:12:35AM +0100, Richard Biener wrote:
> On Thu, Mar 27, 2025 at 8:14 PM Andrew MacLeod <amacl...@redhat.com> wrote:
> >
> > This patch backports the ASSUME support that was rewritten in GCC 15.
> >
> > Its slightly more complicated than the port to GCC 14 was in that a few
> > classes have been rewritten. I've isolated them all to tree-assume.cc
> > which contains the pass.
> >
> > It has to also bring in the ssa_cache and lazy_ssa_cache from gcc14,
> > along with some tweaks to those classes to deal with changes in the way
> > range_allocators worked started in GCC14. Those changes are are all the
> > top of the tree-assume.cc file. The rest of the file is a carbon copy of
> > the GCC14 version. (well, what should be... there is an outstanding
> > debug output support that was never submitted I discovered)
> >
> > I'm not sure if its worth putting this in GCC13 or not, but I will
> > submit it and leave it to the release managers :-) It should be low
> > risk, especially since assume was experimental support?
>
> I have no strong opinion here besides questioning whether it's
> necessary (as you say, assume is experimental) and the fact that
> by splicing out the VRP changes to a special place further maintenance
> is made more difficult.
>
> IMO, up to you (expecting you'll fix issues if they come up), but would
> like to hear a 2nd opinion from Jakub.
I'd probably apply it, it was a wrong-code issue and I'm not sure
users understand assume as experimental.
While the [[assume (...)]]; form is a C++23 feature which is experimental,
we accept that attribute even since C++11 and in C23 and in the
__attribute__((assume (...))); form everywhere and as a documented
extension.
If the ranger changes are done only when users actually use assume rather
than all the time (and only when using non-trivial assumptions, trivial
ones with no side-effects are turned into if (!x) __builtin_unreachable ()),
I think this decreases the risks.
Jakub
