https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
--- Comment #3 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> The issue seems to be that if-conversion isn't done:
>
> Can not ifcvt due to multiple exits
>
> maybe my patched dev tree arrives with a different CFG here (no switches
> into ifcvt). I don't think if-conversion was adjusted when the vectorizer
> gained early exit vectorization
it was adjusted only to deal with bitfield lowering which was one of the
scenarios we had on the roadmap.
> - if-conversion shouldn't for example
> predicate with the exit condition and it should leave those conditions
> and exits around.
How would if-cvt recover what reassoc did here though?
<bb 3> [local count: 1044213920]:
# s_15 = PHI <s_9(9), s_6(D)(8)>
_1 = *s_15;
if (_1 > 63)
goto <bb 11>; [50.00%]
else
goto <bb 4>; [50.00%]
<bb 11> [local count: 522106960]:
goto <bb 5>; [100.00%]
<bb 4> [local count: 522106960]:
_14 = (int) _1;
_17 = 9223372036854785024 >> _14;
_18 = _17 & 1;
_19 = _18 == 0;
_12 = ~_19;
<bb 5> [local count: 1044213920]:
# prephitmp_4 = PHI <_12(4), 0(11)>
_10 = _1 == 92;
_13 = prephitmp_4 | _10;
if (_13 != 0)
goto <bb 12>; [8.03%]
else
goto <bb 6>; [91.97%]
is the relevant block, wouldn't BB4 need to be fully predicated to be able to
vectorize this? That also pushes this loop to only be vectorizable when fully
masked where the original input doesn't require masking.
As a side note, it looks like it's reassoc that's transforming and merging the
conditions, i.e. https://godbolt.org/z/9Kfafvava
I wonder if this transformation is really beneficial on modern cpus though.
Seems like the compares are independent so the entire thing executes quite
parallel?
