On Tue, Nov 10, 2020 at 02:09:20PM -0700, Jeff Law wrote:
>
> On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
> >> Eric Botcazou <botca...@adacore.com> wrote:
> >>
> >>>> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3()
> >>>> functions
> >>>> is rather bad, it yields bad machine code at least on i386 and AMD64.
> >>>> Since
> >>>> GCC knows how to shift integers twice the register size these functions
> >>>> can
> >>>> be written as one-liners.
> >>> These functions are precisely meant to be used when GCC cannot do that.
> >> On which processor(s) is GCC unable to generate code for DWtype shifts?
> > E.g. avr-none, msp430-elf, pdp11-aout.
> > And I see recursive __cmpdi2 calls on avr-none too.
>
> ACK. I'll pull those [u]cmpdi changes. They were iffy at best, this
> confirms the concerns we both had.
To be precise, I haven't tried to build libgcc for all of those, just
checked what code is produced for
unsigned long long foo (unsigned long long x) { return x << 3; }
etc. by all trunk cross-compilers I have lying around.
It might be that their __ashlDI3 etc. are actually __ashlsi3 and they
have some other implementation of __ashldi3 etc.
Anyway, I'm not sure if we really need to optimize too much functions which
are never used; and the -ftrapv stuff should one day be reimplemented using
-fsanitize=signed-integer-overflow with an abort behavior on overflows.
libgcc functions which are used heavily of course should be optimized as
much as possible.
Jakub
