On Tue, May 24, 2016 at 12:02 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, May 24, 2016 at 10:49 AM, Jakub Jelinek <jakub@redhat.com> wrote:

>>> Since vinsertf64x2 is an CpuAVX512VL instruction, I don't see
>>> why it shouldn't assemble.
>>
>> Is it?  I believe only vinsertf32x4 is, vinsertf64x2 is
>> CpuAVX512VL & CpuAVX512DQ:
>>
>> EVEX.NDS.256.66.0F3A.W0 18 /r ib        T4      V/V     AVX512VL        Insert 128 bits of packed single-precision floating-
>> VINSERTF32X4 ymm1 {k1}{z}, ymm2,                        AVX512F         point values from xmm3/m128 and the remaining
>> xmm3/m128, imm8                                                         values from ymm2 into ymm1 under writemask k1.
>>
>> EVEX.NDS.512.66.0F3A.W0 18 /r ib        T4      V/V     AVX512F         Insert 128 bits of packed single-precision floating-
>> VINSERTF32X4 zmm1 {k1}{z}, zmm2,                                        point values from xmm3/m128 and the remaining
>> xmm3/m128, imm8                                                         values from zmm2 into zmm1 under writemask k1.
>>
>> EVEX.NDS.256.66.0F3A.W1 18 /r ib        T2      V/V     AVX512VL        Insert 128 bits of packed double-precision floating-
>> VINSERTF64X2 ymm1 {k1}{z}, ymm2,                        AVX512DQ        point values from xmm3/m128 and the remaining
>> xmm3/m128, imm8                                                         values from ymm2 into ymm1 under writemask k1.
>>
>> EVEX.NDS.512.66.0F3A.W1 18 /r ib        T2      V/V     AVX512DQ        Insert 128 bits of packed double-precision floating-
>> VINSERTF64X2 zmm1 {k1}{z}, zmm2,                                        point values from xmm3/m128 and the remaining
>> xmm3/m128, imm8                                                         values from zmm2 into zmm1 under writemask k1.
>>
>> vinsertf64x2, 4, 0x6618, None, 1, CpuAVX512DQ|CpuAVX512VL, Modrm|EVex=3|Masking=3|VexOpcode=2|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=4|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|XMMword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegYMM, RegYMM }
>>
>> At least in 319433-024.pdf I see in 5.1.5:
>>
>> The fourth column holds abbreviated CPUID feature flags (e.g. appropriate
>> bits in CPUID.1:ECX, CPUID.1:EDX for SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AVX/F16C support; bits in
>> CPUID.(EAX=07H,ECX=0):BCX for AVX2/AVX512F etc) that indicate processor support for the instruction. If
>> the corresponding flag is ‘0’, the instruction will #UD.
>>
>> Therefore, my understanding is that you need all the mentioned flags enabled
>> or it will #UD.  Does binutils treat CpuAVX512DQ|CpuAVX512VL instead
>> as the insn being enabled in either .arch .avx512vl, or .arch .avx512dq
>> alone, rather than only in .arch .avx512vl; .arch .avx512dq ?
>>
>
> I opened:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=20140
>

This is what I checked in.


-- 
H.J.