https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #37 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #36)
> For example with AVX512VL and the following, using -O -fgimple -mavx512vl
> we get simply
>
> notl %esi
> orl %esi, %edi
> cmpb $15, %dil
> je .L6
>
> typedef long v4si __attribute__((vector_size(4*sizeof(long))));
> typedef v4si v4sib __attribute__((vector_mask));
> typedef _Bool sbool1 __attribute__((signed_bool_precision(1)));
>
> void __GIMPLE (ssa) foo (v4sib v1, v4sib v2)
> {
> v4sib tem;
>
> __BB(2):
> tem_5 = ~v2_2(D);
> tem_3 = v1_1(D) | tem_5;
> tem_4 = _Literal (v4sib) { _Literal (sbool1) -1, _Literal (sbool1) -1,
> _Literal (sbool1) -1, _Literal (sbool1) -1 };
> if (tem_3 == tem_4)
> goto __BB3;
> else
> goto __BB4;
>
> __BB(3):
> __builtin_abort ();
>
> __BB(4):
> return;
> }
>
>
> the question is whether that matches the semantics of GIMPLE (the padding
> is inverted, too), whether it invokes undefined behavior (don't do it - it
> seems for people using intrinsics that's what it is?) or whether we
> should avoid affecting padding.
>
> Note after the patch I proposed on the mailing list the constant mask is
> now expanded with zero padding.
I think we should also mask off the upper bits of variable mask?
notl %esi
orl %esi, %edi
notl %edi
andl $15, %edi
je .L3
