On 11/7/2013 6:23 PM, Richard Henderson wrote: > On 11/07/2013 06:31 AM, Tom Musta wrote: >> The single-precision scalar arithmetic instructions all interpret the most >> significant 64 bits of a VSR as a single precision floating point number >> stored in double precision format (similar to the standard PowerPC floating >> point single precision instructions). Thus a common theme in the supporting >> code is rounding of an intermediate double-precision number to single >> precision. > > Modulo my comments wrt the actual computation of fma, the patches all look > fine. > > But I'd like to also mention a pre-existing flaw/niggle in the ppc port. > > The conversions to/from in-register representation for the single-precision > values should never raise exceptions. Yet we always use > > d.d = float32_to_float64(f.f, &env->fp_status); > f.f = float64_to_float32(d.d, &env->fp_status); > > The use of env->fp_status is either wrong or extremely misleading. It sure > looks like the operation affects global cpu state. It may be that that state > is never copied back to the "real" fpscr and so doesn't actually affect cpu > state, but how can I see that for sure? > > I think it would be better to implement ConvertSPtoDP_NP and ConvertSP64toSP > exactly as written in the spec. > > Or at minimum use a dummy fp_status that's not associated with env. It should > not matter what the "real" rounding mode is in either case, since values that > are not exactly representable as single-precision values give undefined > results.
Richard: Thanks for your comments. I concur with this comment on fp_status. I am looking into the comments on fused multiply-add.
