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

[Zong Li <zongbox at gmail dot com>]

Joseph Myers <joseph@codesourcery.com> 於 2018年10月22日 週一 下午8:11寫道：
>
> 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.

I see, I would change the __FP_FRAC_SUB_3, __FP_FRAC_SUB_4,
__FP_FRAC_ADD_3 and __FP_FRAC_ADD_4 implementation, let the interface
is identical for users.