On Sat, 15 Oct 2011, Walter Lee wrote: > +FPBIT_FUNCS := $(filter-out \ > + _addsub_sf _mul_sf _div_sf _negate_sf \ > + _eq_sf _ne_sf _le_sf _lt_sf _ge_sf _gt_sf \ > + _sf_to_di _sf_to_si _sf_to_udi _sf_do_usi \ > + _di_to_sf _si_to_sf _udi_to_sf _usi_to_sf, \ > + $(FPBIT_FUNCS)) > + > +DPBIT_FUNCS := $(filter-out \ > + _addsub_df _mul_df _div_df _negate_df \ > + _eq_df _ne_df _le_df _lt_df _ge_df _gt_df \ > + _df_to_di _df_to_si _df_to_udi _df_do_usi \ > + _di_to_df _si_to_df _udi_to_df _usi_to_df, \ > + $(DPBIT_FUNCS))
I'm not clear on quite why you are enabling fpbit at all if you then disable most of the functions from it. What functions do you actually still get from fpbit, how are they used and would it be better to have separate implementations of them? How does the implementation you have used compare in performance with (a) fpbit and (b) soft-fp? (If you have access to EEMBC, that's quite good as a benchmark of software floating-point performance; see the paper in the 2006 GCC Summit proceedings; other floating-point-heavy benchmarks could probably be used as well.) Since you have two architectures, one of which has both 32-bit and 64-bit variants, benchmarks should probably be given for all three cases. -- Joseph S. Myers jos...@codesourcery.com
