http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58122
Anthony Foiani <anthony.foiani at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anthony.foiani at gmail dot com
--- Comment #2 from Anthony Foiani <anthony.foiani at gmail dot com> ---
Using this build of 4.8.1:
$ /usr/local/gcc-4.8.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.8.1/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc-4.8.1
--with-local-prefix=/usr/local/gcc-4.8.1/local --enable-languages=c,c++
--enable-threads --disable-multilib
Thread model: posix
gcc version 4.8.1 (GCC)
With this test case (thanks for the nudge, Oleg!)
#include <stdint.h>
uint64_t test()
{
uint64_t rv = 0;
uint32_t i;
for ( i = 0; i < ITERS; ++i )
rv += i;
return rv;
}
I did a quick loop to find where it switched from precomputing to looping.
Interestingly, it was at 71 (precomputed) to 72 (loop) iterations:
$ for i in {1..100} ;
do
/usr/local/gcc-4.8.1/bin/gcc -O3 -S test.c -DITERS=$i ;
if grep -q jne test.s ;
then
echo "$i: loop" ;
else
echo "$i: precomputed" ;
fi ;
done
1: precomputed
2: precomputed
3: precomputed
4: precomputed
5: precomputed
...
70: precomputed
71: precomputed
72: loop
73: loop
Curious whether the 17/71 difference from Oleg's SH environment is a
typo/transposition, or if it's a difference in native word size, or something
else.
For whatever it's worth, this bug is not something that is affecting me; it was
just a question brought up on the IRC channel. So I don't have any priority to
assign to it, other than that it seems a regression in
quality-of-implementation since 4.7. (Although, as I asked in my original
e-mail, it might be that 4.8 is just more cautious about looping, so the
correct flags could restore the desired performance.)
Thanks,
Tony
