qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 17/29] tcg: Add gvec expanders for vector shi


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH v2 17/29] tcg: Add gvec expanders for vector shift by scalar
Date: Thu, 2 May 2019 08:46:27 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/2/19 7:37 AM, Alex Bennée wrote:
>> +void tcg_gen_gvec_shls(unsigned vece, uint32_t dofs, uint32_t aofs,
>> +                       TCGv_i32 shift, uint32_t oprsz, uint32_t maxsz)
>> +{
>> +    static const TCGOpcode scalar_list[] = { INDEX_op_shls_vec, 0 };
>> +    static const TCGOpcode vector_list[] = { INDEX_op_shlv_vec, 0 };
>> +    static gen_helper_gvec_2 * const fno[4] = {
>> +        gen_helper_gvec_shl8i,
>> +        gen_helper_gvec_shl16i,
>> +        gen_helper_gvec_shl32i,
>> +        gen_helper_gvec_shl64i,
>> +    };
>> +
>> +    tcg_debug_assert(vece <= MO_64);
>> +    do_gvec_shifts(vece, dofs, aofs, shift, oprsz, maxsz,
>> +                   vece == MO_32 ? tcg_gen_shl_i32 : NULL,
>> +                   vece == MO_64 ? tcg_gen_shl_i64 : NULL,
>> +                   tcg_gen_shls_vec, tcg_gen_shlv_vec, fno[vece],
>> +                   scalar_list, vector_list);
> 
> Hmm I guess:
> 
>     static GVecGenFoo const ops[4] = {
>         {
>             .fno = gen_helper_gvec_shl8i
>         },
>         {
>             .fno = gen_helper_gvec_shl16i
>         },
>         {
>             .fno = gen_helper_gvec_shl32i,
>             .fni4 = tcg_gen_shl_i32
>         },
>         {
>             .fno = gen_helper_gvec_shl64i,
>             .fni8 = tcg_gen_shl_i64
>         }
>     };
>     tcg_debug_assert(vece <= MO_64);
>     do_gvec_shifts(vece, dofs, aofs, shift, oprsz, maxsz, &ops[vece],
>                    tcg_gen_shls_vec, tcg_gen_shlv_vec,
>                    scalar_list, vector_list);
> 
> gets a little verbose....

That's exactly it.

The GVecGenFoo structures were created so that front ends would be able to
define their own.  For that I wanted full generality.  This case didn't seem to
warrant that.

I suppose I could create a denser GVecGenFoo for this case.
Which actually seems like a good idea now I think about it.

r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]