Re: [PATCH 1/2] soft-fp: Fix overwritten issue for division in op-4.h

[Joseph Myers <joseph at codesourcery dot com>]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com