On 28.02.19 19:22, Richard Henderson wrote:
> On 2/28/19 2:54 AM, David Hildenbrand wrote:
>> Hmm, as v2 and v3 are handled concatenated it is not that easy. I am not
>> sure if we can handle this without a temporary vector.
>>
>> I thought about packing them first interleaved
>>
>> v2 = [v2e0, v2e1]
>> v3 = [v3e0, ve31]
>> v1 = [v2e0_packed, v3e0_packed, v2e1_packed, v3e1_packed]
>>
>> And then restoring the right order
>>
>> v1 = [v2e0_packed, v2e1_packed, v3e0_packed, v3e1_packed]
>>
>> But than the second operation seems to be the problem. That shuffling
>> would have to be hard coded as far as I can see. (shuffling with MO_8 is
>> nasty -> 14 element shave to be exchanged, in my opinion needing
>> eventually 14 temporary variables)
>
> I suppose you could do it in registers.
>
> load_element_i64(t1, v2, 0);
> for (i = 1; i < N; i++) {
> load_element_i64(t3, v2, i, es);
> tcg_gen_deposit_i64(t1, t1, t3, i << es, 1 << es);
> }
> // repeat for v3 into t2
> // store t1,t2 into v1.
>
> Now you have only 3 temporaries, which is manageable.
>
> The only question, when it comes to MO_8, is whether the code expansion of
> this
> is reasonable (16 byte loads, 15 deposits, 2 stores -- minimum 33 insns,
> probably 48 for x86_64 host), or whether a helper function would be better in
> the end. But then the same is true for all of the other merge & unpack
> operations wrt MO_8.
And it would only apply when dst==src. Will have a try what looks "less
ugly" :) Thanks!
>
>
> r~
>
--
Thanks,
David / dhildenb
