https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96466
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #3)
> It's the same store as PR96453: copyprop can eliminate that to:
>
> Folding statement: _3 = { 5 };
> Queued stmt for removal. Folds to: { 5 }
> Folding statement: _4 = VEC_COND_EXPR <_3 > { 4441221374 }, { -1 }, { 0 }>;
> gimple_simplified to _4 = { 0 };
> Folded into: _4 = { 0 };
>
> @Richi: Can we teach copyprop to fold constant expressions for
> VEC_COND_EXPRs that have first argument equal to a constant?
Not sure what you are asking for - copyprop already does constant folding.
Also wouldn't -fno-tree-copy-prop then re-introduce the issue? Doesn't
the issue exist with -O0 when always_inline is used? Hmm, no, then I see
<bb 2> :
x_3 = 5;
v_4 = { 4441221375 };
x.0_5 = x_3;
_6 = {x.0_5};
_7 = v_4 <= _6;
_8 = VEC_COND_EXPR <_7, { -1 }, { 0 }>;
_9 = VIEW_CONVERT_EXPR<V>(_8);
_13 = VIEW_CONVERT_EXPR<long unsigned int>(_9);
_14 = _13 & 4441221375;
v_10 = {_14};
_11 = v_10;
fed into ISEL which makes it happy.
OK, so ISEL does not like
_4 = { 0 };
_5 = VEC_COND_EXPR <_4, { -1 }, { 0 }>;
but I think it has to cope with this situation. I can imagine even
sth like
_4 = { 0 };
_5 = _4;
_6 = VEC_COND_EXPR <_5, { -1 }, { 0 }>;
thus a stray copy. Or a more complex boolean vector like { 0, -1, 0, -1 }
or so. For a constant it should be possible to fake a compare generating
it, say, for
(vector(2) <signed-boolean:64>) { 0, -1 }
use (signed:64){ 0, -1 } != (signed:64){ 0, 0 }
of course for a general SSA boolean vector there's no way to build it up
if the target cannot code-generate it by itself.
Note that if you'd have
_4 = { 0, -1 };
_5 = VEC_COND_EXPR <_4, a_7, b_8>;
then while you can constant-fold away the condition you will end up
with a VEC_PERM which might not be supported either. So faking a
compare is IMHO better here.
