[RFC] PPC hardfpu for instructions that don't alter FPSCR.FI

[vcoracolombo]

This is a very simple patch written on top of #76 which tries to enable hardfpu for PPC targets. Specifically, this RFC makes the changes for multiply-add instructions to be able to use hardfpu.

if (!(fpscr_mask & FP_FI) && (env->fpscr & FP_FI)) {                  \
    float_exception_flags |= float_flag_inexact;                \
}                                                                     \

The construct above allows the inexact flag to be set when

1. The instruction does not alter FPSCR.FI. This is important because this bit is not emulated correctly with hardfpu, so we want it to be guaranteed to not be changed.
2. The FI bit is already set.

Having the inexact flag set in float_exception_flags is a requirement for the hardfpu code to work (see can_use_fpu() in fpu/softfloat.c)

The problem with this solution is that it would only be able to enable hardfpu for a small set of instructions (those which don't alter FI). I think the list of all instructions which would work with this idea is:

• xscmp* and xvcmp*
• xsmax* and xvmax*
• xsmin* and xvmin*
• xstdivdp and similar
• xvadd*
• xvmul*
• xvdiv*
• xvcv*
• xv[n]madd* and xv[n]msub*
• xvr*

Which are only a subset of vector and vsx instructions. For floating point instructions, we need to think in another solution. For now, this RFC is for the instructions that can benefit from the 'not alter FI' behavior

I did some testing and the results and the FPSCR flags seem to be emulated correctly with these patches applied. However, I can't get rid of the feeling that I'm not understanding something and it might not be that simple. Can anyone think of a situation this won't work?

[vcoracolombo]

This is a very simple patch written on top of #76 which tries to enable hardfpu for PPC targets. Specifically, this RFC makes the changes for multiply-add instructions to be able to use hardfpu.

if (!(fpscr_mask & FP_FI) && (env->fpscr & FP_FI)) {                  \

After some thinking, I think if (!(fpscr_mask & FP_FI) && (env->fpscr & FP_XX)) { might be better. FI still doesn't need to be changed, and XX is already set and sticky so it won't need to be changed also. This would allow this case to be hit more frequently.

[vcoracolombo]

Change to be based on #81, and use FP_XX as the condition instead of FP_FI

@mferst ping