https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122305
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |16.0
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Blocks| |53947
Keywords| |missed-optimization
Last reconfirmed| |2025-10-17
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's a related duplicate bug for this. The issue at times was that the
lane-reducing optabs are not precisely enough specified as to which lanes are
reduced. For the situation here, when all lanes are reduced in the end
eventually that's irrelevant of course.
The reason this fails here is pattern detection is gated on a discovered
recursion, but for BB vect we discover the reduction after this.
I want to move most pattern detection to SLP, so this is a good opportunity.
And for lane-reducing operations this is even more obvious a "SLP pattern".
But for general use even without reduction context nailing down optab
semantics precisely would be nice. IIRC only some of the optabs specify
that input lanes are accumuated to "overlapping" output lanes, but tree.def
doesn't say anything about this. It's required to check all targets
implementing the optabs to see whether they adhere to this semantic
(otherwise always accumulating all lanes to output lane zero and having
zero in the other lanes would be valid).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
