rth@xxxxxxxxxxx writes:
> On 01/10/2014 09:12 AM, Peter Maydell wrote:
>> + for (i = 0; i < elements; i++) {
>> + switch (opcode) {
>> + case 1: /* UZP1/2 */
>> + {
>> + int midpoint = elements / 2;
>> + if (i < midpoint) {
>> + read_vec_element(s, tcg_res, rn, 2 * i + part, size);
>> + } else {
>> + read_vec_element(s, tcg_res, rm,
>> + 2 * (i - midpoint) + part, size);
>> + }
>> + break;
>> + }
>
> You're generating up to 16 * 3 + 2 = 50 opcodes here. I do wonder if it
> wouldn't be better to implement these as helpers. But,
What's the hit in terms of opcodes for calling a helper function? I
would have thought you spend 10s of opcodes with messing around with
stack frames and the like before you get to the helper.
I was wondering if there is a demand for more SIMD like TCG opcodes but
I suspect all the arches are subtly different enough to make it a pain
to abstract.
>
> Reviewed-by: Richard Henderson <rth@xxxxxxxxxxx>
>
>
> r~
--
Sent with my mu4e
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
