On 06/26/2018 05:52 AM, Alex Bennée wrote:
>> +#define DO_LDFF1(PART, FN, TYPEE, TYPEM, H)                             \
>> +static void do_sve_ldff1##PART(CPUARMState *env, void *vd, void *vg,    \
>> +                               target_ulong addr, intptr_t oprsz,       \
>> +                               bool first, uintptr_t ra)                \
>> +{                                                                       \
>> +    intptr_t i = 0;                                                     \
>> +    do {                                                                \
>> +        uint16_t pg = *(uint16_t *)(vg + H1_2(i >> 3));                 \
>> +        do {                                                            \
>> +            TYPEM m = 0;                                                \
>> +            if (pg & 1) {                                               \
>> +                if (!first &&                                           \
>> +                    page_check_range(addr, sizeof(TYPEM), PAGE_READ)) { \
>> +                    record_fault(env, i, oprsz);                        \
>> +                    return;                                             \
>> +                }                                                       \
>> +                m = FN(env, addr, ra);                                  \
>> +                first = false;                                          \
>> +            }                                                           \
>> +            *(TYPEE *)(vd + H(i)) = m;                                  \
>> +            i += sizeof(TYPEE), pg >>= sizeof(TYPEE);                   \
>> +            addr += sizeof(TYPEM);                                      \
>> +        } while (i & 15);                                               \
>> +    } while (i < oprsz);                                                \
>> +}
>>  \
> So I noticed that the disassembly of these two functions is mostly
> parameter pushing and popping. Is there a case to be made to use the
> __flatten__ approach and see how the compiler unrolls it all?

Em... for the most part the functions being called are not inlinable,
being defined in accel/tcg/.


r~


Reply via email to