On Mon, 22 Oct 2018, Zong Li wrote:
I spend some time to check all the FRAC_ADD and FRAC_SUB use cases.
Thanks for the analysis of the various definitions and users of these
macros.
In conclusion, I inclines to keep the current implementation of
FRAC_SUB_3, FRAC_SUB_4, FRAC_ADD_3 and FRAC_ADD_4 instead of using the
temporary variables like FRAC_ADD_2 and FRAC_SUB_2, and fix the
_FP_DIV_MEAT_N_loop together in next version. Because using temporary
I think a basic principle here should be that all FRAC_ADD and FRAC_SUB
macros have the same interface regarding what overlap is permitted between
arguments and results.
That is, if that interface is defined not to allow any overlap, then there
are several users to change to avoid overlap, even if they are only using
FRAC_ADD macros with overlap between R and Y, or only FRAC_SUB_1 and
FRAC_SUB_2, and so the overlap does not cause problems with the present
implementations.
I think it would be less disruptive to allow exact overlap between
corresponding elements of R and Y. Then __FP_FRAC_SUB_3 and
__FP_FRAC_SUB_4 would be fixed to use temporaries to follow that
interface, while _FP_DIV_MEAT_4_udiv and _FP_DIV_MEAT_N_loop would also be
made to use temporaries so their calls to the FRAC_SUB macros follow that
restriction on overlap. (It's true that the current sfp-machine.h files
only use _FP_DIV_MEAT_1_loop, not _FP_DIV_MEAT_2_loop or
_FP_DIV_MEAT_4_loop, but it's still appropriate to fix _FP_DIV_MEAT_N_loop
to follow the FRAC_SUB interface properly.)
The compiler should have no difficulty optimizing out the temporaries in
cases where they end up not being needed.
In all cases, names of temporary variables in soft-fp macros should start
with the full name of the macro (so __FP_FRAC_SUB_3_* for temporaries
inside __FP_FRAC_SUB_3, for example), to avoid the risk of bugs resulting
from shadowing when one macro calls another macro with the same variable
name.