https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117176
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> Confirmed. SLP early-exit vect related.
>
> (gdb) p operand
> $1 = 1
> (gdb) p debug (slp_node)
> t.c:9:5: note: node 0x4e46ac0 (max_nunits=4, refcnt=1) vector(4)
> <signed-boolean:64>
> t.c:9:5: note: op template: _3 = ~_2;
> t.c:9:5: note: [l] stmt 0 _3 = ~_2;
> t.c:9:5: note: children 0x4e46b50
>
> for some reason vectorizable_comparison_1 is called on this stmt. ISTR
> we expect a comparison here, not a BIT_NOT - SLP discovery should probably
> reject this case (for now).
I think this is a failure of boolean lowering. The vectorizer doesn't handle
mask inversions through bitwise NOT and instead expects vect_recog_bool_pattern
to lower this to a BIT_XOR_EXPR instead.
The problem here is that the comparison that uses the BIT_NOT_EXPR is hidden
inside the gcond so vect_recog_gcond_pattern doesn't find it.
Think the proper solution is to have vect_recog_gcond_pattern do the lowering
since patterns can't be seeds of other patterns atm. That's why the condition
split off from vect_recog_gcond_pattern doesn't trigger
vect_recog_bool_pattern.
So Mine.
