On Fri, Oct 3, 2014 at 1:03 PM, Kirill Yukhin <kirill.yuk...@gmail.com> wrote:
> Hello Uroš,
> On 29 Sep 10:08, Uros Bizjak wrote:
>> On Fri, Sep 26, 2014 at 4:09 PM, Kirill Yukhin <kirill.yuk...@gmail.com>
>> wrote:
>> > +(define_insn "avx512bw_pmaddubsw512<mode><mask_name>"
>> > + [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
>> > + (unspec:VI2_AVX512VL
>> > + [(match_operand:<dbpsadbwmode> 1 "register_operand" "v")
>> > + (match_operand:<dbpsadbwmode> 2 "nonimmediate_operand" "vm")]
>> > + UNSPEC_PMADDUBSW512))]
>> > + "TARGET_AVX512BW"
>> > + "vpmaddubsw\t{%2, %1, %0<mask_operand3>|%0<mask_operand3>, %1, %2}";
>> > + [(set_attr "type" "sseiadd")
>> > + (set_attr "prefix" "evex")
>> > + (set_attr "mode" "XI")])
>> > +
>> Can the one above be described using standard RTX, perhaps something
>> similar to avx2_pmaddubsw256?
> Definetely, it can. We didn't do that because final pattern will be
> twice as long as 256-bit variant resulting to 96 (!) lines and I think
> in near future auto-vect won't pick MADD at all.
> But if you think that it will be better to have explicit RTX, I ready to do
> that!
Uh, no. Let's be reasonable, and put only a comment explaining the
situation, as in case of <sse2_avx2>_psadbw.
Uros.
