https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84327
--- Comment #1 from xyzdr4gon333 at googlemail dot com ---
This bug becomes more important for the actual real-life example which becomes
slower at -O2 compared to -O1! Actually in the earlier attached file you only
have to replace the `interleaveZeros` function with this one:
unsigned int interleaveTwoZeros( unsigned int n )
{
n&= 0x000003ff;
n = (n ^ (n << 16)) & 0xFF0000FF;
n = (n ^ (n << 8)) & 0x0300F00F;
n = (n ^ (n << 4)) & 0x030C30C3;
n = (n ^ (n << 2)) & 0x09249249;
return n;
}
I.e. the only difference are slightly different constants, nothing else! The
timings:
1234567890 iterations took 19.151s and resulted in 806157809
-O0 1234567890 iterations took 19.1547s and resulted in 1772082360
-O1 1234567890 iterations took 5.69619s and resulted in 2085417644
-O2 1234567890 iterations took 6.21504s and resulted in 32256352
-O3 1234567890 iterations took 6.14414s and resulted in 357018037
Not sure if this is worth another bug. Can reproduce this for the following
compiler versions:
for GPP in g++-4.9 g++-5 g++-6 g++-7 g++-8; do
$GPP --version | head -1
for flag in ' ' -O0 -O1 -O2 -O3; do
echo -n "$flag "
$GPP $flag -std=c++11 optimizeFlags.cpp && ./a.out
done
done
g++-4.9 (Debian 4.9.4-2) 4.9.4
1234567890 iterations took 19.1979s and resulted in 1918993912
-O0 1234567890 iterations took 19.1785s and resulted in 710267642
-O1 1234567890 iterations took 5.6609s and resulted in 1898524753
-O2 1234567890 iterations took 5.71375s and resulted in 1117037030
-O3 1234567890 iterations took 5.67933s and resulted in 1451088646
g++-5 (Debian 5.5.0-8) 5.5.0 20171010
1234567890 iterations took 19.2387s and resulted in 999898210
-O0 1234567890 iterations took 19.1464s and resulted in 1358121256
-O1 1234567890 iterations took 5.64181s and resulted in 642760018
-O2 1234567890 iterations took 5.65094s and resulted in 191105767
-O3 1234567890 iterations took 5.68849s and resulted in 1555980094
g++-6 (Debian 6.4.0-12) 6.4.0 20180123
1234567890 iterations took 19.1786s and resulted in 1613186065
-O0 1234567890 iterations took 19.2001s and resulted in 424276129
-O1 1234567890 iterations took 5.73263s and resulted in 1828427433
-O2 1234567890 iterations took 6.16005s and resulted in 814826690
-O3 1234567890 iterations took 6.1438s and resulted in 867162058
g++-7 (Debian 7.3.0-3) 7.3.0
1234567890 iterations took 19.1302s and resulted in 1147954921
-O0 1234567890 iterations took 19.1694s and resulted in 734785107
-O1 1234567890 iterations took 5.72652s and resulted in 1133709951
-O2 1234567890 iterations took 6.15633s and resulted in 352136223
-O3 1234567890 iterations took 6.14089s and resulted in 1468150013
g++-8 (Debian 8-20180207-2) 8.0.1 20180207 (experimental) [trunk revision
257435]
1234567890 iterations took 19.1278s and resulted in 694826541
-O0 1234567890 iterations took 19.1454s and resulted in 249938642
-O1 1234567890 iterations took 5.72959s and resulted in 365780913
-O2 1234567890 iterations took 6.20064s and resulted in 2033700921
-O3 1234567890 iterations took 6.12829s and resulted in 1244532281
=> seems like this is somehow a regression bug since g++ 6!
Actually a mix of -O1 with the additional O2-flags seems to work to reproduce
the weird slowdown!
g++ -O1 "${O2Flags[@]}" -std=c++11 optimizeFlags.cpp && ./a.out
=> 6.16161s
Actually by bisecting the additional O2-flags this can be traced down to
-finline-small-functions ... I will open another bug for this.
