https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122723
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Fixed-size epilog vectorization fails with
>
> t.c:4:21: note: ==> examining statement: patt_39 = (<signed-boolean:1>)
> _26;
> t.c:4:21: note: vect_is_simple_use: operand _3 != 0, type of def: internal
> t.c:4:21: missed: conversion not supported by target.
> t.c:4:21: note: vect_is_simple_use: operand _3 != 0, type of def: internal
> t.c:4:21: note: vect_is_simple_use: operand _3 != 0, type of def: internal
> t.c:1:8: missed: not vectorized: relevant stmt not supported: patt_39 =
> (<signed-boolean:1>) _26;
>
> that's from
>
> t.c:4:21: note: vect_recog_mask_conversion_pattern: detected: _ifc__32 =
> .COND_ADD (_26, sum_18, val_13, sum_18);
> t.c:4:21: note: mask_conversion pattern recognized: patt_40 = .COND_ADD
> (patt_39, sum_18, val_13, sum_18);
> t.c:4:21: note: extra pattern stmt: patt_39 = (<signed-boolean:1>) _26;
>
> this is another place where one of my earlier cleanups regressed and we
> lookup
> stmts from the representative stmt rather than the SLP node (this is the
> pattern stmts from the main loop analysis).
Hmm, no, for V8DFmode we unpack the 64bit mask to 8 8bit masks, but for the
V4DFmode epilog we'd have a 32bit mask and require unpacking to 8 4bit masks,
something we fail to do because we're not really special-casing mask
vectors in vectorizable_conversion. We have vec_unpacks_sbool_{hi,lo} for
this but for a multi-step conversion we're not considering this only
for the second step.
