On Fri, Jan 06, 2017 at 10:27:46AM +0530, Bharata B Rao wrote: > On Fri, Jan 06, 2017 at 09:01:17AM +1100, David Gibson wrote: > > On Thu, Jan 05, 2017 at 04:56:08PM +0530, Nikunj A Dadhania wrote: > > > From: Bharata B Rao <bhar...@linux.vnet.ibm.com> > > > > > > Use float64 argument instead of unit64_t in helper_compute_fprf() > > > This allows code in helper_compute_fprf() to be reused later to > > > work with float128 argument too. > > > > > > Signed-off-by: Bharata B Rao <bhar...@linux.vnet.ibm.com> > > > Signed-off-by: Nikunj A Dadhania <nik...@linux.vnet.ibm.com> > > > > Uh.. how can this possibly be correct, without updating the callers of > > helper_compute_fprf()? > > It works currently because uint64_t argument that is passed by the > callers is interpreted as float64 arg (via farg.d). > > Let me see if there is a cleaner way of doing this. Casting the > callers with right floatXX type seems to be the easiest way. > The requirement here is to ensure that > > helper_compute_fprf_float16(CPUPPCState *env, float16 arg) > helper_compute_fprf_float32(CPUPPCState *env, float32 arg) > helper_compute_fprf_float64(CPUPPCState *env, float64 arg) > helper_compute_fprf_float128(CPUPPCState *env, float128 arg) > > get autogenerated with right floatXX argument so that it can directly > be used with required routines (like floatXX_is_any_nan etc) w/o > needing the CPU_DoubleU or other intermediate forms.
Ok. I think some of this explanation needs to go into the commit
message.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
