Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Jeff Law <law@redhat.com>]

On 11/25/20 2:22 PM, Stefan Kanthak wrote:
> Jakub Jelinek <jakub@redhat.com> wrote:
>
>> On Wed, Nov 25, 2020 at 09:22:53PM +0100, Stefan Kanthak wrote:
>>>> As Jakub has already indicated, your change will result in infinite
>>>> recursion on avr.Ã, I happened to have a cr16 handy and it looks like
>>>> it'd generate infinite recursion there too.
>>> JFTR: does GCC emit a warning then? If not: why not?
>> Why should it.  libgcc is something GCC has full control over and can assume
>> it is written in a way that it can't recurse infinitely, that is one of
>> libgcc design goals.
> Where are these design goals documented?
The internals manual is the best source of information on these
routines.  But the implications of what you're going to read there won't
be clear unless you think hard and probably spend some time working with
embedded targets.  Jakub is absolutely, 100% correct here.

>>> Since I neither have an avr nor a cr16 here, and also no TR-440, no S/3x0,
>>> no Spectra-70, no PDP-11, no VAX, no SPARC, no MIPS, no PowerPC, no MC68k,
>>> no NSC16xxx and no NSC32xxx any more, GCC only gives me access to the x86
>>> code it generates.
>> You can always use cross-compilers.
> There are no cross-compilers available here.
> Why should I waste time and energy to build cross-compilers for processors
> I don't use?
If all we had to care about was x86, then your changes would likely be
fine, but GCC targets dozens of distinct processors from deeply embedded
to mainframes and we have to consider how changes impact all of them,
both from a correctness and from a performance standpoint.

By understanding how your proposed changes affect other processors, you
can write better changes that are more likely to get included. 
Furthermore you can focus efforts on things that matter more in the real
world.  DImode shifts in libgcc are _not_ useful to try and optimize on
x86_64 as it has instructions to implement 64 bit shifts.  DImode shifts
in libgcc are not useful to try and optimize on i686 as the compiler can
synthesize them on i686.  DImode shifts can't be easily synthesized on
other targets and on those targets we call the routines in libgcc2. 
Similarly for other routines you find in libgcc2.



>
> [...]
>
>> As has been said multiple times, trying to optimize routines that are never
>> called on x86 for x86
> According to Andreas Schwab, the 64-bit shift routines are called on 32-bit
> processors when compiling with -Os!
> x86 is a 32-bit processor.
He's making a generalization.  It's not going to apply to every 32bit
processor.  Nor would it even necessarily apply to every 16 bit
processor.  But I'm not sure what the point of arguing about this is. 
What you're trying to do with the shift routines is wrong.

>
>> is just wasted energy, better invest your time in
>> functions that are actually ever called.
> Where is the documentation that names the routines (not) called on the >50
> target architectures?
Nobody's bothered to document that.  I don't think doing so would
ultimately be useful.   I do think there is some documentation on what
we used to call libgcc1 as those routines have typically been provided
as assembly code on the targets where they're needed (think 32bit
arithmetic on something like an 8 or 16 bit target).  I haven't looked
at or needed to look for that documentation in over 20 years, so I don't
know if it's still around.


> And why do you build and ship routines which are never called at all?
> This is a waste of time, space and energy!
They are used on some and not others.

I'm sorry you think it's a waste of time space and energy.  These bits
have a purpose and it would be more work than it's worth to try and
selectively build and ship these routines on a target by target basis. 
They're part of the source tree, they get built into the library and
when they are actually needed, they will be used.  As a generality
you're going to find that most are not needed on x86.  So spending time
optimizing them for x86 just isn't all that useful.

jeff