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

[Zong Li <zongbox at gmail dot com>]

Palmer Dabbelt <palmer@dabbelt.com> 於 2018年10月23日 週二 上午3:31寫道：
>
> On Mon, 22 Oct 2018 05:10:59 PDT (-0700), joseph@codesourcery.com wrote:
> > 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.
>
> Thanks for digging in to this so deeply, I'm afraid I'm way over my head here.
> If you need any help feel free to ask, as I'm not really following any of this.

OK, thanks!