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. But the abs changes and the other other multiply changes have undesired LIBGCC2_BAD_CODE ifdefs that you need to clean up before we could accept those changes. 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 :-) But I put them through my tester and couldn't see any evidence that they're causing problems though and reviewed the generated code on m32r since it was convenient to do so. Also note the ucmpdi changes require updating the prototype in libgcc2.h, otherwise you get build failures building gcc itself. I fixed that minor omission. So with all that in mind, I installed everything except the bits which have the LIBGCC2_BAD_CODE ifdefs after testing on the various crosses. If you could remove the ifdefs on the abs/mult changes and resubmit them it'd be appreciated. Jeff
