Relocatable dist
Hi, while trying to make the binary-distribution logic work for cross compilers. I've come wonder, how hard it could be to make GHC relocatable. (e.g. just unpack the distribution, and use the compiler from the `bin` folder within). Right now this does not work due to the need for the path to package.conf, and this is hardcoded in the wrapper script to provide the proper libdir to ghc via -B[1]. Supposedly this is not an issue on Windows, as a relative path is common on windows and finding the location of the executable can be done safely. Or that's at least how I understand[1]. For macOS there is the haskell-platform, and ghc-dot-app[2] From [3], it sounds like automake is a build, and not a packaging system, and the binary dist usecase with configure is not really a standard use case. So why do I bring this up NOW? Apart from me trying to make cross compiler binary distributions working? The reason is that we are also trying to move towards hadrian, and by "starting from scratch", maybe we have a chance to reconsider how we do things? I must admit, I'm quite happy to use packages like llvm, by just downloading a package and adding the `bin` path to my $PATH. There is however one thing that the current configure appraoch does, which I think is quite noteworthy (apart from setting $prefix). That is, it does check for compilers and sets them accordingly, which might be desirable. Cheers, Moritz -- [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg5.html ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Is stage-1 sufficient to run nofib
Hi Edward, Am Sonntag, den 22.10.2017, 22:23 -0400 schrieb Edward Z. Yang: > Yes, but you still need to build the libraries, so the speed up > will not be as much as you might hope. sure, but when you build every GHC commit, then even a small improvement is nice. Do you know the proper way of building only libraries + ghc-stage1? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Is stage-1 sufficient to run nofib
Yes, but you still need to build the libraries, so the speed up will not be as much as you might hope. Excerpts from Joachim Breitner's message of 2017-10-22 22:19:03 -0400: > Hi, > > I guess I could just try it, but maybe someone knows it, or knows what > would go wrong… > > If I run nofib with ghc-stage1 instead of ghc-stage2, I should get > the same results, right? (ignoring compilation times here) > > My hope is that it can speed up perf.haskell.org some more. > > Greetings, > Joachim > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Is stage-1 sufficient to run nofib
Hi, I guess I could just try it, but maybe someone knows it, or knows what would go wrong… If I run nofib with ghc-stage1 instead of ghc-stage2, I should get the same results, right? (ignoring compilation times here) My hope is that it can speed up perf.haskell.org some more. Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
Thanks! Looking at the llvm ir file, we find: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32" target triple = "armv6-unknown-linux-gnueabihf" that does looks incorrect for armv7l softabi. We have the hardfloat gnueabi, AND armv6. However, I don't know if this influences the generated IR to the point where it's unusable. Looking at https://github.com/ghc/ghc/blob/95c1feeb9ce9b2d6a9453dc4da148b80a5ddce3d/compiler/llvmGen/LlvmCodeGen/Ppr.hs#L35-L86 I don't see a proper configuration for it yet though. Now again we mix the llvm and gcc toolchain, and I don't have gcc on my system right now. We can do the following though: $ llc -O3 StgStartup.ll -o StgStartup.s $ clang --target=arm-unknown-linux-gnueabihf -c StgStartup.s -v and have this successfully produce an object file. As such I don't think the target triple given above is at fault here (apart from potentially generating hard-float fp). I would as such conclude that the issue is the argument passed to gcc as assembler here. I'm a bit at a loss how to solve this here right now. GHC HEAD has seen especially in this area quite a bit of churn as well. On top of my head, I've two suggestions: - Try configuring with a LLVM toolchain. E.g. CC=arm-linux-gnueabi-clang - Try GHC HEAD. If this still fails, you could try to sidestep the mangling and assembly logic, by adding -fast-llvm to the mk/flavour/.mk (e.g. quick-cross, perf-cross). Cheers, Moritz > On Oct 22, 2017, at 4:05 PM, shif...@nanotek.info wrote: > > October 22, 2017 11:51 AM, "Moritz Angermann" > wrote: > >> Can you rerun that command with -keep-llvm-files and attach the generated >> .ll file? >> > > I rerun the same command by adding -keep-llvm-files and the file > "./rts/StgStartup.ll" has been created. Please find it attached. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
October 22, 2017 11:51 AM, "Moritz Angermann" wrote: > Can you rerun that command with -keep-llvm-files and attach the generated .ll > file? > I rerun the same command by adding -keep-llvm-files and the file "./rts/StgStartup.ll" has been created. Please find it attached. StgStartup.ll Description: Binary data ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Compiling natively GHC for ARMv7l softabi
Can you rerun that command with -keep-llvm-files and attach the generated .ll file? Cheers, Moritz Sent from my iPhone > On 22 Oct 2017, at 3:06 PM, shif...@nanotek.info wrote: > > October 22, 2017 10:37 AM, "Moritz Angermann" > wrote: > >> Could you try running this with `-v`? Hopefully, this time will will not >> stop somewhere in the middle, but rather give us the full output, and >> also reproduce the errors. >> > > > Understood. > > # inplace/bin/ghc-stage1 -v -static -O -H64m -Wall -Iincludes > -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS > -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build > -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen >-O2-Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o > rts/dist/build/StgStartup.o > Glasgow Haskell Compiler, Version 8.2.1, stage 1 booted by GHC version 8.2.1 > Using binary package database: > /tmp/ghc-8.2.1/inplace/lib/package.conf.d/package.cache > package flags [] > loading package database /tmp/ghc-8.2.1/inplace/lib/package.conf.d > wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 > wired-in package integer-simple mapped to integer-simple-0.1.1.1 > wired-in package base mapped to base-4.10.0.0 > wired-in package rts mapped to rts > wired-in package template-haskell mapped to template-haskell-2.12.0.0 > wired-in package ghc mapped to ghc-8.2.1 > wired-in package dph-seq not found. > wired-in package dph-par not found. > Created temporary directory: /tmp/ghc32190_0 > *** C Compiler: > arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE > -DNOSMP -E -I includes -I includes/dist -I > includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I > rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/./autogen -I > /tmp/ghc-8.2.1/libraries/base/include -I /tmp/ghc-8.2.1/rts/dist/build -I > /tmp/ghc-8.2.1/includes -I > /tmp/ghc-8.2.1/includes/dist-derivedconstants/header -include > /tmp/ghc-8.2.1/includes/ghcversion.h -Dlinux_BUILD_OS -Dx86_64_BUILD_ARCH > -Dlinux_HOST_OS -Darm_HOST_ARCH '-D__GLASGOW_HASKELL_LLVM__=309' > -D__GLASGOW_HASKELL_TH__ -include/tmp/ghc32190_0/ghc_2.h -x > assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc32190_0/ghc_1.cmmcpp > *** ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]: > !!! ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]: finished in 2.50 milliseconds, > allocated 1.737 megabytes > *** LLVM CodeGen: > *** LLVM CodeGen: > Using LLVM version: (3,9) > *** CmmLint [Cmm$ghc_1.cmmcpp]: > !!! CmmLint [Cmm$ghc_1.cmmcpp]: finished in 0.35 milliseconds, allocated > 0.082 megabytes > !!! LLVM CodeGen: finished in 9.53 milliseconds, allocated 5.082 megabytes > *** LLVM Optimiser: > /usr/bin/opt-3.9 /tmp/ghc32190_0/ghc_4.ll -o /tmp/ghc32190_0/ghc_6.bc -O2 > '--enable-tbaa=true' > *** LLVM Compiler: > /usr/bin/llc-3.9 -O3 '-relocation-model=static' /tmp/ghc32190_0/ghc_6.bc -o > /tmp/ghc32190_0/ghc_7.lm_s '--enable-tbaa=true' > *** LLVM Mangler: > !!! LLVM Mangler: finished in 0.81 milliseconds, allocated 0.369 megabytes > *** Assembler: > arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE > -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build > -Irts/dist/build/./autogen -x assembler -c /tmp/ghc32190_0/ghc_8.s -o > rts/dist/build/StgStartup.o > /tmp/ghc32190_0/ghc_8.s: Assembler messages: > > /tmp/ghc32190_0/ghc_8.s:41:0: error: > Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM > mode > | > 41 | ldrdr0, r1, [r3, #64] > | ^ > > /tmp/ghc32190_0/ghc_8.s:46:0: error: > Error: selected processor does not support `strd r0,r1,[r3,#64]' in ARM > mode > | > 46 | strdr0, r1, [r3, #64] > | ^ > > /tmp/ghc32190_0/ghc_8.s:108:0: error: > Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM > mode >| > 108 | ldrdr0, r1, [r2, #64] >| ^ > > /tmp/ghc32190_0/ghc_8.s:111:0: error: > Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM > mode >| > 111 | strdr0, r1, [r2, #64] >| ^ > > /tmp/ghc32190_0/ghc_8.s:137:0: error: > Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM > mode >| > 137 | ldrdr0, r1, [r2, #64] >| ^ > > /tmp/ghc32190_0/ghc_8.s:140:0: error: > Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM > mode >| > 140 | strdr0, r1, [r2, #64] >| ^ > > /tmp/ghc32190_0/ghc_8.s:163:0: error: > Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM > mode >| > 163 | ldrdr0, r1, [r2, #64] >| ^ > > /tmp/ghc32190_0/ghc_8.s:166:0: error: > Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM > mode >| > 166 |
Re: Compiling natively GHC for ARMv7l softabi
October 22, 2017 10:37 AM, "Moritz Angermann" wrote: > Could you try running this with `-v`? Hopefully, this time will will not > stop somewhere in the middle, but rather give us the full output, and > also reproduce the errors. > Understood. # inplace/bin/ghc-stage1 -v -static -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2-Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o Glasgow Haskell Compiler, Version 8.2.1, stage 1 booted by GHC version 8.2.1 Using binary package database: /tmp/ghc-8.2.1/inplace/lib/package.conf.d/package.cache package flags [] loading package database /tmp/ghc-8.2.1/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-simple mapped to integer-simple-0.1.1.1 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. Created temporary directory: /tmp/ghc32190_0 *** C Compiler: arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -DNOSMP -E -I includes -I includes/dist -I includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/./autogen -I /tmp/ghc-8.2.1/libraries/base/include -I /tmp/ghc-8.2.1/rts/dist/build -I /tmp/ghc-8.2.1/includes -I /tmp/ghc-8.2.1/includes/dist-derivedconstants/header -include /tmp/ghc-8.2.1/includes/ghcversion.h -Dlinux_BUILD_OS -Dx86_64_BUILD_ARCH -Dlinux_HOST_OS -Darm_HOST_ARCH '-D__GLASGOW_HASKELL_LLVM__=309' -D__GLASGOW_HASKELL_TH__ -include/tmp/ghc32190_0/ghc_2.h -x assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc32190_0/ghc_1.cmmcpp *** ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]: !!! ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]: finished in 2.50 milliseconds, allocated 1.737 megabytes *** LLVM CodeGen: *** LLVM CodeGen: Using LLVM version: (3,9) *** CmmLint [Cmm$ghc_1.cmmcpp]: !!! CmmLint [Cmm$ghc_1.cmmcpp]: finished in 0.35 milliseconds, allocated 0.082 megabytes !!! LLVM CodeGen: finished in 9.53 milliseconds, allocated 5.082 megabytes *** LLVM Optimiser: /usr/bin/opt-3.9 /tmp/ghc32190_0/ghc_4.ll -o /tmp/ghc32190_0/ghc_6.bc -O2 '--enable-tbaa=true' *** LLVM Compiler: /usr/bin/llc-3.9 -O3 '-relocation-model=static' /tmp/ghc32190_0/ghc_6.bc -o /tmp/ghc32190_0/ghc_7.lm_s '--enable-tbaa=true' *** LLVM Mangler: !!! LLVM Mangler: finished in 0.81 milliseconds, allocated 0.369 megabytes *** Assembler: arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -x assembler -c /tmp/ghc32190_0/ghc_8.s -o rts/dist/build/StgStartup.o /tmp/ghc32190_0/ghc_8.s: Assembler messages: /tmp/ghc32190_0/ghc_8.s:41:0: error: Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM mode | 41 | ldrdr0, r1, [r3, #64] | ^ /tmp/ghc32190_0/ghc_8.s:46:0: error: Error: selected processor does not support `strd r0,r1,[r3,#64]' in ARM mode | 46 | strdr0, r1, [r3, #64] | ^ /tmp/ghc32190_0/ghc_8.s:108:0: error: Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode | 108 | ldrdr0, r1, [r2, #64] | ^ /tmp/ghc32190_0/ghc_8.s:111:0: error: Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode | 111 | strdr0, r1, [r2, #64] | ^ /tmp/ghc32190_0/ghc_8.s:137:0: error: Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode | 137 | ldrdr0, r1, [r2, #64] | ^ /tmp/ghc32190_0/ghc_8.s:140:0: error: Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode | 140 | strdr0, r1, [r2, #64] | ^ /tmp/ghc32190_0/ghc_8.s:163:0: error: Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode | 163 | ldrdr0, r1, [r2, #64] | ^ /tmp/ghc32190_0/ghc_8.s:166:0: error: Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode | 166 | strdr0, r1, [r2, #64] | ^ *** Deleting temp files: Deleting: /tmp/ghc32190_0/ghc_8.s /tmp/ghc32190_0/ghc_7.lm_s /tmp/ghc32190_0/ghc_6.bc /tmp/ghc32190_0/ghc_5.c /tmp/ghc32190_0/ghc_4.ll /tmp/ghc32190_0/ghc_3.rsp /tmp/ghc32190_0/ghc_2.h /tmp/ghc32190_0/ghc_1.cmmcpp Warning: deleting non-existent /tmp/ghc32190_0/ghc_5.c *** Deleting temp dirs: Deleting: /tmp/ghc32190_0 `arm-linux-gnueabi-gcc' fa
