Re: [Qemu-devel] [PATCH 02/21] target-s390x: split FPU ops

[Richard Henderson <rth@twiddle.net>]

On 09/04/2012 12:40 PM, Blue Swirl wrote:
> On Tue, Sep 4, 2012 at 6:42 PM, Richard Henderson <rth@twiddle.net> wrote:
>> On 09/02/2012 10:33 AM, Blue Swirl wrote:
>>> +/* fpu_helper.c */
>>> +uint32_t set_cc_f32(float32 v1, float32 v2);
>>> +uint32_t set_cc_f64(float64 v1, float64 v2);
>>> +uint32_t set_cc_nz_f32(float32 v);
>>> +uint32_t set_cc_nz_f64(float64 v);
>>> +
>>
>> I think that the CC handling should stay together, regardless of FPU-ness.
>> These functions are quite small and can be usefully inlined by the compiler.
>>
>> OTOH, this is much easier to do with my translate.c rewrite, so maybe I'll
>> just take responsibility for moving them back...
> 
> The problem is that these are used by some FPU ops as well as
> condition code ops. Maybe it's better to move them to cpu.h as inline
> functions?

Maybe...

> It could be also possible to upgrade condition code functions to full
> helpers, that could help implementing lazy condition code evaluation.

Done and ...

> I noticed that the helpers don't use TCGv registers for register
> access but instead the helpers access env->regs[] and env->fregs[]
> directly, this probably would need to be changed too.

done, in my rewrite.

Except for float128, where we can't return such by value inside TCG.
And, annoyingly, s390 float128 values are held in %fN/%fN+2, so the
values are not contiguous in memory.  I momentarily considered passing
a pointer to %fN, letting the helper access f[0]/f[2], but in the end
I didn't consider that any better than just passing the integer N.

So after the rewrite, set_cc_nz_f32/64 are not referenced from the fp
helpers directly.  We still reference set_cc_nz_f128 from ADXBR and SDXBR.


r~