On Tue, Nov 10, 2020 at 08:29:58AM -0700, Jeff Law via Gcc-patches wrote:
> On 10/5/20 10:49 AM, Stefan Kanthak wrote:
> > The implementation of the functions __absv?i2(), __addv?i3() etc. for
> > trapping integer overflow provided in libgcc2.c is rather bad.
> > Same for __cmp?i2() and __ucmp?i2()
> >
> > At least for AMD64 and i386 processors GCC creates awful to horrible
> > code for them: see <https://skanthak.homepage.t-online.de/gcc.html>
> > for some examples as well as the expected assembly.
> >
> > The attached diff/patch provides better implementations.
>
> So you didn't indicate how this was tested.  The addition, subtraction,
> negation and mulvsi3 are reasonable. The mulvsi3 change introduced a
> failure on m32r, but I'm highly confident it's an pre-existing simulator
> bug.
The formatting is wrong too (e.g. no space before ( when calling functions).
> What I don't understand is why the [u]cmpdi/cmpdi2 changes don't cause
> infinite recursion.  I would expect the comparisons you're using to
> compute the return value to themselves trigger calls to [u]cmpdi2. I
> can speculate that the expanders are open-coding the comparison, but in
> that case I'd expect the libgcc2 routines to never be used, so
> optimizing them is pointless :-)
Yeah, I don't really understand these changes either.
Jakub
