On 29 Mar 19:49, Jakub Jelinek wrote:
> On Tue, Mar 29, 2016 at 11:44:15AM -0600, Jeff Law wrote:
> > On 03/29/2016 11:05 AM, Jakub Jelinek wrote:
> > >Hi!
> > >
> > >The various blendm expanders look like:
> > >(define_insn "<avx512>_blendm<mode>"
> > > [(set (match_operand:V48_AVX512VL 0 "register_operand" "=v")
> > > (vec_merge:V48_AVX512VL
> > > (match_operand:V48_AVX512VL 2 "nonimmediate_operand" "vm")
> > > (match_operand:V48_AVX512VL 1 "register_operand" "v")
> > One could argue this ordering is just asking for trouble.
>
> I bet the reason for this ordering are both the x86 intrinsics and
> the HW behavior (see e.g. the order of arguments in the insn template
> of the define_insn, etc.).
> I think VEC_MERGE's definition on which argument you pick the elements from
> for 0 bits in the mask vs. 1 bits in the mask is the exact opposite of what
> the x86 HW wants and the intrinsics expect.
I think that order of arguments in built-in might be changed easily.
This doesn't affect intrinsics at all, because of that.
I can hardly recall, but my bet is that this order was dictated by:
ix86_expand_sse_movcc where order of blends args should corresond
on AVX*.
If we want to fix the order in the pattern we should swap op_[true|false]
here:
case V64QImode:
gen = gen_avx512bw_blendmv64qi;
break;
case V32HImode:
gen = gen_avx512bw_blendmv32hi;
break;
case V16SImode:
gen = gen_avx512f_blendmv16si;
break;
case V8DImode:
gen = gen_avx512f_blendmv8di;
break;
case V8DFmode:
gen = gen_avx512f_blendmv8df;
break;
case V16SFmode:
gen = gen_avx512f_blendmv16sf;
break;
Jakub, nay be add comment in the patch on blendm patterns emphasizing
this non-regular order?
Otherwise, patch is OK to me.
--
Thanks, K
>
> Jakub
