On 10 November 2012 05:11, "Frank Müller" franky1976@gmx.net wrote:
Michael Hope michael.hope@linaro.org:
My suspicion is that we/crosstool-NG enable extra features like Graphite or GCC is built with a different level of checking. If you
I suspected Graphite as well and removed it in my own builds without noticable difference.
have the time, could you check the flags passed to GCCs configure? You can do this on Ubuntu using:
apt-get build-dep gcc apt-get source gcc dpkg-buildpackage -uc -us -b
and compare the configure line with the one in crosstool-NG's build.log.
Isn't this the same as gcc -v? I've posted the lines at http://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002913.html
Good point. There's nothing obvious in the list. Ubuntu explicitly adds --enable-checking=release but it's the default for release branches like ours.
I can reproduce the slowdown in a smaller testcase. Compiling pcre with -O3 -mfpu=neon -march=armv7-a -mtune=cortex-a8 takes 18.8 s for the Ubuntu Precise 4.6 compiler, 17.8 s for the Ubuntu Quantal 4.7 compiler, and 41.2 s for the Linaro 4.7 2012.10 build. I've logged LP: #1077739 to track. I'll spin a --enable-checking=release build just to check.
The above lines do not work for me, the last line misses a changelog file:
# dpkg-buildpackage -uc -us -b tail: cannot open `debian/changelog' for reading: No such file or directory dpkg-buildpackage: error: tail of debian/changelog gave error exit status 1
Yip, you need to change to the just-extracted source directory first.
-- Michael
On 11 November 2012 22:18, Michael Hope michael.hope@linaro.org wrote:
On 10 November 2012 05:11, "Frank Müller" franky1976@gmx.net wrote:
Michael Hope michael.hope@linaro.org:
My suspicion is that we/crosstool-NG enable extra features like Graphite or GCC is built with a different level of checking. If you
I suspected Graphite as well and removed it in my own builds without noticable difference.
have the time, could you check the flags passed to GCCs configure? You can do this on Ubuntu using:
apt-get build-dep gcc apt-get source gcc dpkg-buildpackage -uc -us -b
and compare the configure line with the one in crosstool-NG's build.log.
Isn't this the same as gcc -v? I've posted the lines at http://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002913.html
Good point. There's nothing obvious in the list. Ubuntu explicitly adds --enable-checking=release but it's the default for release branches like ours.
I can reproduce the slowdown in a smaller testcase. Compiling pcre with -O3 -mfpu=neon -march=armv7-a -mtune=cortex-a8 takes 18.8 s for the Ubuntu Precise 4.6 compiler, 17.8 s for the Ubuntu Quantal 4.7 compiler, and 41.2 s for the Linaro 4.7 2012.10 build. I've logged LP: #1077739 to track. I'll spin a --enable-checking=release build just to check.
Does perf give any clues?
On 12 November 2012 14:17, Mans Rullgard mans.rullgard@linaro.org wrote:
On 11 November 2012 22:18, Michael Hope michael.hope@linaro.org wrote:
On 10 November 2012 05:11, "Frank Müller" franky1976@gmx.net wrote:
Michael Hope michael.hope@linaro.org:
My suspicion is that we/crosstool-NG enable extra features like Graphite or GCC is built with a different level of checking. If you
I suspected Graphite as well and removed it in my own builds without noticable difference.
have the time, could you check the flags passed to GCCs configure? You can do this on Ubuntu using:
apt-get build-dep gcc apt-get source gcc dpkg-buildpackage -uc -us -b
and compare the configure line with the one in crosstool-NG's build.log.
Isn't this the same as gcc -v? I've posted the lines at http://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002913.html
Good point. There's nothing obvious in the list. Ubuntu explicitly adds --enable-checking=release but it's the default for release branches like ours.
I can reproduce the slowdown in a smaller testcase. Compiling pcre with -O3 -mfpu=neon -march=armv7-a -mtune=cortex-a8 takes 18.8 s for the Ubuntu Precise 4.6 compiler, 17.8 s for the Ubuntu Quantal 4.7 compiler, and 41.2 s for the Linaro 4.7 2012.10 build. I've logged LP: #1077739 to track. I'll spin a --enable-checking=release build just to check.
Does perf give any clues?
I think I've found the problem. We pass -U_FORTIFY and -fno-stack-protector to make the binary more universal, and the way that crosstool-NG passes these flags on to the tool overrides the default package flags and turns off any optimisations.
Short story: GCC was being built without optimisations. I've got a test build running to verify.
-- Michael
Am 12.11.2012 03:27, schrieb Michael Hope:
I think I've found the problem. We pass -U_FORTIFY and -fno-stack-protector to make the binary more universal, and the way that crosstool-NG passes these flags on to the tool overrides the default package flags and turns off any optimisations.
Short story: GCC was being built without optimisations. I've got a test build running to verify.
setting STAGE1_CFLAGS should not overwrite the CFLAGS used for the build. Setting these flags for a native stage3 build should not be necessary. The stage1 compiler isn't shipped.
On 13 November 2012 22:58, Matthias Klose doko@ubuntu.com wrote:
Am 12.11.2012 03:27, schrieb Michael Hope:
I think I've found the problem. We pass -U_FORTIFY and -fno-stack-protector to make the binary more universal, and the way that crosstool-NG passes these flags on to the tool overrides the default package flags and turns off any optimisations.
Short story: GCC was being built without optimisations. I've got a test build running to verify.
setting STAGE1_CFLAGS should not overwrite the CFLAGS used for the build. Setting these flags for a native stage3 build should not be necessary. The stage1 compiler isn't shipped.
With our configuration, crosstool-NG sets CFLAGS to -pipe -fno-stack-protector -U_FORTIFY. This overrides the default -O2 -g for later stages and gives us an unoptimised GCC.
The test build has just come in. Before:
michaelh@crucis:$ time arm-linux-gnueabihf-gcc ... -O3 -mfpu=neon -c -o pcre_compile.lo pcre_compile.c
real 0m5.752s user 0m5.692s sys 0m0.040s
After:
real 0m2.689s user 0m2.640s sys 0m0.036s
Frank, I've put a test build up at: http://people.linaro.org/~michaelh/incoming/gcc-linaro-arm-linux-gnueabihf-4...
Could you give it a try? I'll commit the fix now and it'll be part of the end of month release.
-- Michael
Hi,
Michael Hope michael.hope@linaro.org:
With our configuration, crosstool-NG sets CFLAGS to -pipe -fno-stack-protector -U_FORTIFY. This overrides the default -O2 -g for later stages and gives us an unoptimised GCC.
The test build has just come in. Before:
michaelh@crucis:$ time arm-linux-gnueabihf-gcc ... -O3 -mfpu=neon -c -o pcre_compile.lo pcre_compile.c
real 0m5.752s user 0m5.692s sys 0m0.040s
After:
real 0m2.689s user 0m2.640s sys 0m0.036s
Frank, I've put a test build up at:
http://people.linaro.org/~michaelh/incoming/gcc-linaro-arm-linux-gnueabihf-4...
Could you give it a try? I'll commit the fix now and it'll be part of the end of month release.
I just tried it and can confirm the fix. Compile time for this version is now equal to the Ubuntu version (down from 12 to 7 minutes). Thank you so much for solving this, I'd never have figured this out on my own!
Frank
linaro-toolchain@lists.linaro.org
-
"Frank Müller" -
Mans Rullgard -
Matthias Klose -
Michael Hope