https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63599
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The tree level looks like this:
t_13 = VEC_COND_EXPR <t_4 <= { 4.142135679721832275390625e-1,
4.142135679721832275390625e-1, 4.142135679721832275390625e-1,
4.142135679721832275390625e-1 }, t_4, _12>;
ret_14 = VEC_COND_EXPR <t_4 > { 4.142135679721832275390625e-1,
4.142135679721832275390625e-1, 4.142135679721832275390625e-1,
4.142135679721832275390625e-1 }, { 7.85398185253143310546875e-1,
7.85398185253143310546875e-1, 7.85398185253143310546875e-1,
7.85398185253143310546875e-1 }, { 0.0, 0.0, 0.0, 0.0 }>;
t_16 = _9 != 0 ? t_13 : t_4;
ret_15 = _9 != 0 ? ret_14 : { 0.0, 0.0, 0.0, 0.0 };
>"movmskps %xmm8, %edx"
> does not protect the code in the if block...
Yes it does just not the way you think it does.
Notice the last two statements are conditional expressions.
And that gets translated into the following:
testl %edx, %edx
jne .L9
movaps %xmm3, %xmm1
pxor %xmm2, %xmm2
.L9:
So if anything it is a missed optimization dealing with conditional moves with
vectors without a vector comparison.
