After milestone 3 it is natural to proceed to milestone 4. Unfortunately this was not so easy and in fact it’s not reached yet thanks to the LLVM issue. Anyway, I’ve started with this mk/build.mk file:
GhcUnregisterised=YES GhcWithNativeCodeGen=NO SplitObjs=NO GhcLibWays=v GhcStage1HcOpts = GhcStage2HcOpts = -fllvm -opta=-march=armv7a GhcLibHcOpts = -fllvm -opta=-march=armv7a SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO
It basically means that I’ll build stage1 compiler with C backend, but stage2 compiler and its libraries with LLVM backend. Everything was going well till the moment stage1 compiler attempts to build stage2 compiler Parser.hs file. This file is kind of tricky, it’s Happy generated Haskell file from the Haskell grammar definition in Happy format. So, well, automatically generated Haskell file. And this makes LLVM screaming. Well, perhaps LLVM was not screaming, but the board surely was, since LLC stayed compiling this file for 7 hours and yet without a result! I’ve submitted this as an Infinite loop in llc on ARMv7 bug into LLVM bug database. Eli Friedman’s note in a comment 4 make it sound a little bit more optimistically (hopefully no infinite loop!), but still O(N^3) problem complexity is not something I’d like to stress my board on — also keep in mind I’m using unoptimized LLVM builds on ARM since this is the best build I can have with available GNU C++ compiler. At the end I worked around this issue by switching back to C backend just for this file.
Anyway, this was the only one issue of the build, otherwise it went fine and testsuite give me those results:
OVERALL SUMMARY for test run started at Sat Jun 25 10:12:25 CEST 2011 2802 total tests, which gave rise to 7180 test cases, of which 0 caused framework failures 3289 were skipped 3721 expected passes 102 expected failures 0 unexpected passes 68 unexpected failures Unexpected failures: 2014(normal) 2228(normal) 2636(normal) 3171(normal) 3586(normal) 3890(normal) 4850(normal) T2615(llvm,normal) T3016(llvm,normal) T3736(normal) T3807(normal) T3953(normal) T4801(normal) T4891(normal) T4978(normal) T706(normal) ann01(llvm,normal) annfail03(normal) annfail04(normal) annfail05(normal) annfail06(normal) annfail07(normal) annfail08(normal) annfail09(normal) annfail10(normal) annfail12(normal) annrun01(llvm,normal) apirecomp001(normal) cabal04(normal) dph-diophantine-opt(normal) dph-dotp-fast(normal) dph-dotp-opt(normal) dph-primespj-opt(normal) dph-quickhull-opt(normal) dph-sumnats(normal) dph-words-opt(normal) ghc-e001(normal) ghc-e002(normal) ghc-e003(normal) ghc-e004(normal) ghc-e005(normal) ghci024(normal) ghci037(normal) ghcpkg05(normal) hpc_ghc_ghci(normal) jmp_tbl(llvm) layout007(normal) massive_array(llvm,normal) qq001(normal) qq002(normal) qq003(normal) qq004(normal) qq007(llvm,normal) qq008(llvm,normal) recomp007(normal) tcrun006(llvm,normal) tcrun007(llvm,normal) tcrun029(llvm,normal)
If you compare this with Milestone 3 results you will see that results are identical except two “solved” timed out testcases (solved by increasing timeout value) and 3424 testcase which now does not fail. It failed due to GCC’s cc1 process being killed for whatever reason I don’t know, but I suspect Linux’s OOM killer for this. So if I compare this then it seems I got the same and expected results, which is very optimistic, but still I need to wait and see how/when LLVM team is going to solve the reported issue to properly reach the milestone 4, but in parallel I’ll of course work on milestone 5 already…