Hello,
I'm interested in LLVM correct performance on ARM hardware and it looks like LLVM is kind of sensitive to what GCC version is used for its compilation. I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro 2011.05 and 4.6.1 Linaro 2011.06. Please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/
It looks like LLVM HEAD does have about 28 regressions in comparison with LLVM 2.9. But also Linaro's GCC 4.6.1s do have some regressions in comparison with older GCC 4.3.4 and 4.4.1. Also what is really interesting with LLVM is how much tests fails when compiled with -O2 or default -O3 compilation option. I don't know if the culprit here is LLVM code or just GCC miscompilation/overoptimization?
Is there any testing I may do to help you fix those regressions?
Thanks, Karel
On Mon, Jul 4, 2011 at 8:39 AM, Karel Gardas karel.gardas@centrum.cz wrote:
Hello,
I'm interested in LLVM correct performance on ARM hardware and it looks like LLVM is kind of sensitive to what GCC version is used for its compilation. I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro 2011.05 and 4.6.1 Linaro 2011.06. Please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/
It looks like LLVM HEAD does have about 28 regressions in comparison with LLVM 2.9. But also Linaro's GCC 4.6.1s do have some regressions in comparison with older GCC 4.3.4 and 4.4.1. Also what is really interesting with LLVM is how much tests fails when compiled with -O2 or default -O3 compilation option. I don't know if the culprit here is LLVM code or just GCC miscompilation/overoptimization?
Is there any testing I may do to help you fix those regressions?
Hi Karel. That's an interesting idea - you've ended up using LLVM to test GCC. I'm not sure the source of these problems, but the first step is to treat these as an application bug and investigate from there. Load LLVM up in GDB, put a breakpoint in the assert, and see if the values look valid. Try building LLVM with -fno-strict-aliasing to see if LLVM is doing something unusual. See if a cross-compiled LLVM has the same faults.
It'll be interesting to see how this turns out.
-- Michael
On 3 July 2011 22:39, Karel Gardas karel.gardas@centrum.cz wrote:
I don't know if the culprit here is LLVM code or just GCC miscompilation/overoptimization?
Another interesting test you could run: How does it compare to LLVM built with itself (clang)?
If the same errors happen, it is rather unlikely gcc is doing something wrong.
ttyl bero
linaro-toolchain@lists.linaro.org