And now another PR was opened (120887). so perhaps I should apply it.
If I don't hear a dissenting opinion, I'll Apply it monday PM to GCC 13.
It is completely self contained to uses of complex ASSUME's as Jakub
suggests it is...
Andrew
On 3/28/25 05:25, Jakub Jelinek wrote:
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
