Jeff Law <l...@redhat.com> wrote: [...]
> 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. What makes you think that my patches addressed only i386 and AMD64? Again: from the absence of __addDI3/__subDI3 in libgcc2.[ch] I had reason to assume that GCC synthesizes "double-word" addition/subtraction on all processors, not just on x86. Since "double-word" comparision and shifts are likewise simple operations I further assumed that GCC synthesizes them too on all processors. What's the fundamental difference between subtraction and comparision? Why does GCC generate calls to __[u]cmpDI2 for a simple comparision instead to synthesize it? And: as shown in libgcc2.c, "double-word" shifts can easily be synthesized using "single-word" shifts plus logical OR on any target. I expected GCC to synthesize these operations on non-x86 processors too, just like "double-word" addition and subtraction. A possible/reasonable explanation would be code size, i.e. if the synthesized instructions need significantly more memory than the function call (including the argument setup of course). Stefan
