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.
Jakub
