- ghc-devs - Haskell.org

Haddock is broken in head?
by Páli Gábor János 24 Sep '13

24 Sep '13

Hi there, I have been recently experiencing some problems with haddock in head on FreeBSD, spotted by both of my builder clients [1,2], but quite reproducible on a recent FreeBSD system too: [snip] Running hscolour for ghc-prim-0.3.1.0... Preprocessing library ghc-prim-0.3.1.0... "/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt" --optghc=-hisuf --optghc=hi --optghc=-osuf --optghc=o --optghc=-hcsuf --optghc=hc --optghc=-static --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --optghc=-split-objs --optghc=-dynamic-too --source-module=src/%{MODULE/./-}.html --source-entity=src/%{MODULE/./-}.html#%{NAME} libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /354) in 'GHC.PrimopWrappers' 72% (813 /1123) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20130924 for x86_64-portbld-freebsd): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug gmake[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 gmake: *** [all] Error 2 The attached patch seems to fix the problem, but then I get this: [snip] "/usr/home/foo/ghc/build.20130922/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt" --optghc=-hisuf --optghc=hi --optghc=-osuf --optghc=o --optghc=-hcsuf --optghc=hc --optghc=-static --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --optghc=-split-objs libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /354) in 'GHC.PrimopWrappers' 32% (177 /547) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' attempting to use module 'ghc-prim:GHC.Types' (libraries/ghc-prim/./GHC/Types.hs) which is not loaded gmake[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 gmake: *** [all] Error 2 Any ideas on how to fix this? Thanks, Gabor [1] http://haskell.inf.elte.hu/builders/freebsd-i386-head/21/10.html [2] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/23/10.html

2 2

Re: [Haskell-cafe] Announcing GHC iOS
by Dominick Samperi 23 Sep '13

23 Sep '13

I just tested the GHC support with Xcode 5 and iOS 7 (64-bit) and it seems to work (using the simulator). But I wonder if an app built on this framework would pass Apple's QA filtering process, given that an external binary (.a) file with the Haskell code must be included? Also, the iPhone 5S is the first with 64-bit support, and for best performance all apps should be 64-bit (because then no 32-bit libs need to be loaded, and there are more general purpose and floating point registers in 64-bit mode). Are there any roadblocks preventing the creation of 64-bit GHC/iOS7 apps? Thanks, Dominick On Tue, Sep 3, 2013 at 9:45 PM, Luke Iannini <lukexi(a)me.com> wrote: > That is awesome news : ). CC’ing back the list for posterity now that it’s > sorted. > > I submitted a patch already that fixes the warnings you mentioned there: > http://ghc.haskell.org/trac/ghc/ticket/8208 > > Cheers > Luke > > On Sep 3, 2013, at 6:18 PM, Dominick Samperi <djsamperi(a)gmail.com> wrote: > > Hi Luke, > > Thanks for your help! > > I managed to build (after checking out the snapshot that you > mentioned), successfully generated haskell.a, and > it worked on my simulator. There was a warning message at the end of > the build (make)...I've appended it below. Your iOS Objective-C/Haskell > integration sounds very interesting. I'll be watching ghc-devs for the > latest news on these developments. > > Cheers, > Dominick > > *** Warning issued at end of make *** > > "inplace/bin/ghc-stage1" -o > utils/compare_sizes/dist-install/build/tmp/compareSizes.a -hisuf hi -osuf > o -hcsuf hc -static -H64m -O0 -fllvm -hide-all-packages -i > -iutils/compare_sizes/. -iutils/compare_sizes/dist-install/build > -iutils/compare_sizes/dist-install/build/autogen > -Iutils/compare_sizes/dist-install/build > -Iutils/compare_sizes/dist-install/build/autogen -optP-include > -optPutils/compare_sizes/dist-install/build/autogen/cabal_macros.h -package > base-4.7.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 > -XHaskell98 -no-user-package-db -rtsopts -odir > utils/compare_sizes/dist-install/build -hidir > utils/compare_sizes/dist-install/build -stubdir > utils/compare_sizes/dist-install/build > utils/compare_sizes/dist-install/build/Main.o > > <no location info>: > Warning: Couldn't figure out linker information! > Make sure you're using GNU ld, GNU gold or the built in OS X > linker, etc. > ld: warning: could not create compact unwind for .LFB3: non-standard > register 5 being saved in prolog > ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) > not allowed in code signed PIE, but used in _s1p4_entry from > utils/compare_sizes/dist-install/build/Main.o. To fix this warning, don't > compile with -mdynamic-no-pic or link with -Wl,-no_pie > > > > On Mon, Sep 2, 2013 at 11:46 PM, Luke Iannini <lukexi(a)me.com> wrote: > >> Hi Dominick, great!! Now you’re just hitting a normal GHC build failure >> that apparently hasn’t been fixed yet in HEAD : )). >> >> Check out 98b0d05de35bd531102d832f3108050549fd781f from a few days ago >> and you should be able to build to completion now… >> >> The build process will use a combo of clang and gcc, depending on whether >> it’s building code to run on the host or the target. The core libraries >> that get installed into /usr/local/ghc-ios-sim/lib at the end of the build >> should be i386. >> >> The FFI does indeed only support C, but happily Objective-C is basically >> just syntactic sugar for C and can be called from a completely C API — >> https://github.com/jspahrsummers/ObjectiveHaskell/ is a project that >> takes advantage of this and makes a nicer Objective-C/Haskell bridging >> experience. I’ll have a version up very shortly that’s set up to work with >> GHC iOS. >> >> There’s also some work to do a more native Objective-C FFI underway to >> look forward to : ) >> Cheers >> Luke >> >> On Sep 2, 2013, at 8:09 PM, Dominick Samperi <djsamperi(a)gmail.com> wrote: >> >> Hello Luke, >> >> Thanks for your patience. I configured build.mk with more care, using >> BuildFlavour = quick-llvm, and adding options as needed, for example, >> INTEGER_LIBRARY = integer-simple. I've attached my build.mk. >> >> This seems to have cleared up the terminfo issue, and the build >> ran for a long time, but ultimately it failed with a ghc-stage1 panic >> (the "impossible" happened). I've attached makelog.txt. >> >> I added the following directories at the beginning of PATH: >> 1. ~/bin/ghc/ghc-ios-scripts-master >> 2. ~/bin/clang+llvm-3.0-x86_64-apple-darwin11/bin >> >> The second directory is needed because locate does not find >> lcc or opt on my system, it only finds /usr/bin/clang. >> >> I'm confused by a few things. I'm building for i386-apple-ios (a >> 32 bit architecture), yet the libraries in (2) are for 64bit? Also, it >> is not clear if the build process is using clang or gcc (or gcc-llvm?). >> >> Looking ahead to the time when I get this to work, I'm curious >> about what has been accomplished. The FFI only supports interfaces >> to C, not Objective-C or C++. Thus, it seems to me that to develop >> an app using Haskell only the lowest common denominator >> language can be used, namely C. Is this correct? >> >> Thanks again for your help! >> >> Dominick >> >> >> >> On Mon, Sep 2, 2013 at 6:51 PM, Luke Iannini <lukexi(a)me.com> wrote: >> >>> One more thing to try that might just get you going while we figure out >>> the actual bug: >>> Just go through ghc.mk and delete all the lines that include terminfo >>> (just 394 and 443 I think), then perl boot again. >>> >>> On Sep 1, 2013, at 7:51 PM, Dominick Samperi <djsamperi(a)gmail.com> >>> wrote: >>> >>> OK, I tried your "in the dark" suggestion but there was no >>> change (same problem). >>> >>> I'm attaching configurelog.txt and makelog.txt... >>> >>> >>> On Sun, Sep 1, 2013 at 10:12 PM, Luke Iannini <lukexipd(a)gmail.com>wrote: >>> >>>> Hi Dominick, >>>> >>>> Switching to private just to keep from spamming the list too much : ) >>>> (I'll post again when we figure it out) — could you also send me the output >>>> of ./configure? (e.g. on http://gist.github.com or http://lpaste.net) >>>> >>>> Also, just poking in the dark here: what if you change >>>> ifneq "$(HostOS_CPP)" "ios" >>>> to >>>> ifneq "$(TargetOS_CPP)" "ios" >>>> >>>> on line 393 of ghc.mk and then re-run perl boot/configure? >>>> >>>> Thanks! >>>> Cheers >>>> Luke >>>> >>>> >>>> On Sun, Sep 1, 2013 at 4:58 PM, Dominick Samperi <djsamperi(a)gmail.com>wrote: >>>> >>>>> Hello Luke, >>>>> >>>>> Thanks for the note. I'm testing on OS X 10.8.4, Xcode 4.6.3, and >>>>> llvm-gcc 4.2.1 >>>>> (I placed the scripts directory ghc-ios-scripts-master at the front of >>>>> PATH). >>>>> LVM Build is 2336.11.00. >>>>> >>>>> I fetched GHC sources and tried to build using: >>>>> >>>>> $ git clone git://git.haskell.org/ghc.git >>>>> $ cd ghc >>>>> $ ./sync-all --no-dph get >>>>> >>>>> $ perl boot # after creating mk/build.mk >>>>> $ ./configure --target=i386-apple-darwin11 --prefix=/usr/local/ghc-ios-sim/ >>>>> $ make >>>>> >>>>> # Fails saying terminfo -any is not available >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Sep 1, 2013 at 7:39 PM, Luke Iannini <lukexipd(a)gmail.com>wrote: >>>>> >>>>>> Hi Dominick, >>>>>> Hm, this should have been fixed by >>>>>> http://ghc.haskell.org/trac/ghc/ticket/7700 . >>>>>> >>>>>> When you say you downloaded GHC, do you mean you cloned GHC HEAD >>>>>> (e.g. git clone git://git.haskell.org/ghc.git ?) — the patches have >>>>>> only just landed : ). >>>>>> >>>>>> Also can you give us an idea of what your build environment is? (OS >>>>>> version, Xcode version etc) >>>>>> >>>>>> Cheers >>>>>> Luke >>>>>> >>>>>> >>>>>> On Sun, Sep 1, 2013 at 4:32 PM, Dominick Samperi <djsamperi(a)gmail.com >>>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I followed the instructions on the link, downloaded ghc, created >>>>>>> build.mk, etc., >>>>>>> and configured for ghc-ios-sim. But the make fails with the message >>>>>>> below. >>>>>>> Tried installing terminfo (cabal install terminfo) but this didn't >>>>>>> help... >>>>>>> >>>>>>> ghc $ make >>>>>>> ===--- building phase 0 >>>>>>> make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds >>>>>>> make[1]: Nothing to be done for `phase_0_builds'. >>>>>>> ===--- building phase 1 >>>>>>> make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds >>>>>>> "inplace/bin/ghc-cabal" check utils/ghc-pkg >>>>>>> A 'license-file' is not specified. >>>>>>> "inplace/bin/ghc-cabal" configure utils/ghc-pkg dist-install "" >>>>>>> --with-ghc="/Users/dsamperi/ >>>>>>> bin/ghc/ghc/inplace/bin/ghc-stage1" >>>>>>> --with-ghc-pkg="/Users/dsamperi/bin/ghc/ghc/inplace/bin/ghc-pkg" >>>>>>> --disable-library-for-ghci --disable-library-vanilla >>>>>>> --disable-library-profiling --disable-shared --configure-option=CFLAGS=" >>>>>>> -U__i686 -fno-stack-protector " --configure-option=LDFLAGS=" " >>>>>>> --configure-option=CPPFLAGS=" " >>>>>>> --configure-option=--host=i386-apple-darwin11 >>>>>>> --with-gcc="/Users/dsamperi/bin/ghc/ghc-ios-scripts-master/i386-apple-darwin11-gcc" >>>>>>> --with-ld="/Users/dsamperi/bin/ghc/ghc-ios-scripts-master/i386-apple-darwin11-ld" >>>>>>> --configure-option=--with-cc="/Users/dsamperi/bin/ghc/ghc-ios-scripts-master/i386-apple-darwin11-gcc" >>>>>>> --with-ar="/opt/local/bin/ar" --with-ranlib="ranlib" >>>>>>> --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" >>>>>>> Configuring ghc-pkg-6.9... >>>>>>> ghc-cabal: At least the following dependencies are missing: >>>>>>> terminfo -any >>>>>>> make[1]: *** [utils/ghc-pkg/dist-install/package-data.mk] Error 1 >>>>>>> make: *** [all] Error 2 >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 30, 2013 at 5:04 AM, Simon Peyton-Jones < >>>>>>> simonpj(a)microsoft.com> wrote: >>>>>>> >>>>>>>> Great. Please thank Stephen too.. I don’t have his email.**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Just go ahead and modify **** >>>>>>>> >>>>>>>> http://ghc.haskell.org/trac/ghc/wiki/CodeOwners**** >>>>>>>> >>>>>>>> http://ghc.haskell.org/trac/ghc/wiki/Platforms**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> I assume iOS will become a tier-2 platform?**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Simon**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> *From:* Luke Iannini [mailto:lukexipd@gmail.com] >>>>>>>> *Sent:* 30 August 2013 09:07 >>>>>>>> *To:* Simon Peyton-Jones >>>>>>>> *Cc:* Austin Seipp >>>>>>>> *Subject:* Re: [Haskell-cafe] Announcing GHC iOS**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Certainly! And I'd be happy to take on maintainership of GHC iOS if >>>>>>>> that's what you mean — I've committed to a very large project using it so >>>>>>>> I'll be maintaining it anyway : ). I'd guess Stephen would feel the same. >>>>>>>> **** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> And thanks so much for the kind words, it means the world! Thank >>>>>>>> you infinitely for Haskell : ).**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Cheers**** >>>>>>>> >>>>>>>> Luke**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> On Fri, Aug 30, 2013 at 12:32 AM, Simon Peyton-Jones < >>>>>>>> simonpj(a)microsoft.com> wrote:**** >>>>>>>> >>>>>>>> Should we update the “Platform maintainers” on >>>>>>>> http://ghc.haskell.org/trac/ghc/wiki/TeamGHC**** >>>>>>>> >>>>>>>> or the list of supported platforms on >>>>>>>> http://ghc.haskell.org/trac/ghc/wiki/Platforms?**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] *On >>>>>>>> Behalf Of *Luke Iannini >>>>>>>> *Sent:* 29 August 2013 21:56 >>>>>>>> *To:* Haskell Cafe >>>>>>>> *Subject:* Re: [Haskell-cafe] Announcing GHC iOS**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Stephen provided some more credits — thanks so much to all!**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Three connected projects concerning cross-compilation:**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *Registerised ARM support, added using David Terei's LLVM compiler >>>>>>>> back end with Stephen Blackheath doing an initial ARMv5 version and LLVM >>>>>>>> patch and Karel Gardas working on floating point support, ARMv7 >>>>>>>> compatibility and LLVM headaches. Ben Gamari did work on the runtime linker >>>>>>>> for ARM.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *General cross-compiling, with much work by Stephen Blackheath and >>>>>>>> Gabor Greif (though many others have worked on this).**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *A cross-compiler for Apple iOS. iOS-specific parts were mostly >>>>>>>> Stephen Blackheath with Luke Iannini on the Cabal patch, testing and >>>>>>>> supporting infrastructure, also with assistance and testing by Miëtek Bak >>>>>>>> and Jonathan Fischoff, and thanks to many others for testing; The iOS cross >>>>>>>> compiler was started back in 2009 by Stephen Blackheath with funding from >>>>>>>> Ryan Trinkle of iPwn Studios.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Thanks to Ian Lynagh for making it easy for us with integration, >>>>>>>> makefile refactoring and patience, and to David Terei for LLVM assistance. >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> On Thu, Aug 29, 2013 at 1:43 PM, Luke Iannini <lukexipd(a)gmail.com> >>>>>>>> wrote:**** >>>>>>>> >>>>>>>> Hi all!**** >>>>>>>> >>>>>>>> (in case you don't read /r/haskell : ))**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Stephen Blackheath and I are extremely happy to report that as of >>>>>>>> today, GHC can natively build binaries for iOS devices and the iOS >>>>>>>> Simulator.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> You'll find everything you need here: >>>>>>>> http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS*** >>>>>>>> * >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> The short of it is you can use "ghc-ios myFiles.hs" to get a >>>>>>>> universal ARMv7/ARMv7s/i386 static library to drop straight into an Xcode >>>>>>>> project.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Stephen's already working on some wonderful FRP-powered games, I'm >>>>>>>> working on a project called SpaceTime that I'll announce shortly, and you >>>>>>>> may now all begin creating insanely great iOS software using the finest >>>>>>>> language in the world : ).**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Stephen deserves the lion's share of the credit for this project — >>>>>>>> it's been over 3 years in the making! Many thanks to Maxwell Swadling for >>>>>>>> generalizing static library builds into a -staticlib flag for GHC, Carter >>>>>>>> Schonwald for compilation guidance, and the venerable Austin Seipp for >>>>>>>> reviewing and merging our patches.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> ghc-devs mailing list >>>>>>>> ghc-devs(a)haskell.org >>>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs(a)haskell.org >>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> <configurelog.txt><makelog.txt> >>> >>> >>> >> <makelog.txt><build.mk> >> >> >> > >

2 3

Can we make validate use the same warnings as make?
by Johan Tibell 23 Sep '13

23 Sep '13

Hi, In the past I've been frustrated by validate using other warnings than the default make build and also using -Werror. This causes a bit of frustration and lost time. If we used the same warnings I could have fixed the problem before a time consuming validate. P.S. I just remember this today and I haven't used validate recently so if this was already fixed, my apologies. -- Johan

2 2

Re: [commit: ghc] wip/simd: Enable -msse to be specified by itself. (1ed36c5)
by Johan Tibell 23 Sep '13

23 Sep '13

On Mon, Sep 23, 2013 at 12:12 AM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : wip/simd > Link : http://ghc.haskell.org/trac/ghc/changeset/1ed36c54d50e0e97aee95d15d674f95ca… > >>--------------------------------------------------------------- > > commit 1ed36c54d50e0e97aee95d15d674f95cabab0b77 > Author: Geoffrey Mainland <gmainlan(a)microsoft.com> > Date: Mon Sep 16 12:27:37 2013 -0400 > > Enable -msse to be specified by itself. > > This sets the SSE "version" to 1.0. > > >>--------------------------------------------------------------- > > 1ed36c54d50e0e97aee95d15d674f95cabab0b77 > compiler/main/CmdLineParser.hs | 2 +- > compiler/main/DriverPipeline.hs | 11 +++++------ > compiler/main/DynFlags.hs | 7 +++++++ > 3 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/compiler/main/CmdLineParser.hs b/compiler/main/CmdLineParser.hs > index 6681186..fef2701 100644 > --- a/compiler/main/CmdLineParser.hs > +++ b/compiler/main/CmdLineParser.hs > @@ -220,7 +220,7 @@ processOneArg opt_kind rest arg args > Just min <- parseInt min_s -> Right (f maj min, args) > | [maj_s] <- split '.' rest_no_eq, > Just maj <- parseInt maj_s -> Right (f maj 0, args) > - | otherwise -> Left ("malformed version argument in " ++ dash_arg) > + | otherwise -> Right (f 1 0, args) This looks wrong. Shouldn't we match on [] here? There's still a possibility that the value after -msse is garbage. > > > findArg :: [Flag m] -> String -> Maybe (String, OptKind m) > diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs > index 63f203a..44a6fa5 100644 > --- a/compiler/main/DriverPipeline.hs > +++ b/compiler/main/DriverPipeline.hs > @@ -1414,6 +1414,7 @@ runPhase (RealPhase LlvmLlc) input_fn dflags > > sseOpts | isSse4_2Enabled dflags = ["-mattr=+sse42"] > | isSse2Enabled dflags = ["-mattr=+sse2"] > + | isSseEnabled dflags = ["-mattr=+sse"] > | otherwise = [] > > avxOpts | isAvx512fEnabled dflags = ["-mattr=+avx512f"] > @@ -2033,12 +2034,10 @@ doCpp dflags raw input_fn output_fn = do > -- remember, in code we *compile*, the HOST is the same our TARGET, > -- and BUILD is the same as our HOST. > > - let sse2 = isSse2Enabled dflags > - sse4_2 = isSse4_2Enabled dflags > - sse_defs = > - [ "-D__SSE__=1" | sse2 || sse4_2 ] ++ > - [ "-D__SSE2__=1" | sse2 || sse4_2 ] ++ > - [ "-D__SSE4_2__=1" | sse4_2 ] > + let sse_defs = > + [ "-D__SSE__=1" | isSseEnabled dflags ] ++ > + [ "-D__SSE2__=1" | isSse2Enabled dflags ] ++ > + [ "-D__SSE4_2__=1" | isSse4_2Enabled dflags ] > > let avx_defs = > [ "-D__AVX__=1" | isAvxEnabled dflags ] ++ > diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs > index 37f35e6..d6b386a 100644 > --- a/compiler/main/DynFlags.hs > +++ b/compiler/main/DynFlags.hs > @@ -129,6 +129,7 @@ module DynFlags ( > unsafeGlobalDynFlags, setUnsafeGlobalDynFlags, > > -- * SSE and AVX > + isSseEnabled, > isSse2Enabled, > isSse4_2Enabled, > isAvxEnabled, > @@ -3617,6 +3618,12 @@ setUnsafeGlobalDynFlags = writeIORef v_unsafeGlobalDynFlags > -- check if SSE is enabled, we might have x86-64 imply the -msse2 > -- flag. > > +isSseEnabled :: DynFlags -> Bool > +isSseEnabled dflags = case platformArch (targetPlatform dflags) of > + ArchX86_64 -> True > + ArchX86 -> sseVersion dflags >= Just (1,0) > + _ -> False > + > isSse2Enabled :: DynFlags -> Bool > isSse2Enabled dflags = case platformArch (targetPlatform dflags) of > ArchX86_64 -> -- SSE2 is fixed on for x86_64. It would be > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

1 1

[HEADS UP] simd branch merged
by Geoffrey Mainland 23 Sep '13

23 Sep '13

I have merged the wip/simd branch. Please let me know if you encounter any breakage as a result of the merge. Geoff

1 0

front-end hooks status?
by Nicolas Frisby 22 Sep '13

22 Sep '13

What is the status on the Hooks proposal/documentation/implementation? I'd like to try it out on a pet project. trac/ghc/wiki/Ghc/Hooks is promising, but I don't know where to find the patch to experiment with it. I get a 404 from https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-rec…, a link I found in one of Luite's ghc-devs emails. Exciting work! Thanks.

4 3

Windows validate failure
by Simon Peyton-Jones 22 Sep '13

22 Sep '13

My latest Windows validate fell over as below, with some kind of Python failure (ie not just a failing test). It worked fine couple of days ago. Does anyone have any ideas of what might be going on? Simon =====> process007(normal) 3739 of 3756 [2, 24, 0] cd ../../libraries/process/tests && $MAKE -s --no-print-directory process007_fd process007_fd.c: In function 'main': process007_fd.c:33:46: error: 'EWOULDBLOCK' undeclared (first use in this function) process007_fd.c:33:46: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [process007_fd] Error 1 Traceback (most recent call last): File "../driver/runtests.py", line 279, in <module> oneTest() File "c:\code\HEAD\testsuite\driver\testlib.py", line 549, in <lambda> thisTest = lambda : runTest(myTestOpts, name, func, args) File "c:\code\HEAD\testsuite\driver\testlib.py", line 528, in runTest test_common_work (name, opts, func, args) File "c:\code\HEAD\testsuite\driver\testlib.py", line 686, in test_common_work framework_fail(name, 'runTest', 'Unhandled exception: ' + str(e)) File "c:\code\HEAD\testsuite\driver\testlib.py", line 824, in framework_fail if_verbose(1, '*** framework failure for %s %s ' %s (full_name, reason)) NameError: global name 's' is not defined make[2]: *** [test] Error 1 make[2]: Leaving directory `/c/code/HEAD/testsuite/tests' make[1]: *** [fast] Error 2 make[1]: Leaving directory `/c/code/HEAD/testsuite/tests' make: *** [test] Error 2 == Start post-testsuite package check Timestamp 2013-09-22 02:30:10 UTC for c:/code/HEAD/inplace\lib\package.conf.d\package.cache Timestamp 2013-09-22 02:30:10 UTC for c:/code/HEAD/inplace\lib\package.conf.d (same as cache) using cache: c:/code/HEAD/inplace\lib\package.conf.d\package.cache == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. -------------------------------------------------------------------

2 1

Static Data Re: llvm
by Carter Schonwald 22 Sep '13

22 Sep '13

agreed on most of those points @john, no, that would be deeply wrong and dangerous (i think), the way to have a global IORef is using unsafePerformIO, which is actually quite safe if you have a good reason for introducing a globally visible shared reference. theres probably a bunch of sublties, but the notion of compile time data that the code generator can safely use has a number of awesome applications. One other one would be the ability to have static lookup arrays baked into the binary, rather than generated at runtime. I'll be at icfp tomorrow mid afternoon through at least the first half of the week, i'll pester the relevant folks for feedback and thoughts about this (sub)topic. having static data would tie into a number of features i want in ghc and associated code gen, and I'm quite willing to pester and do the associated engineering to make sure static data, or some more systematic feature thats more general. Good thing i'm decent at pestering and ok at engineering. If there are any technical objections to adding support for static data, i'm all ears. I'm quite willing to do the leg work to make it happen, but its something that will touch enough pieces of GHC's entire pipeline (lightly, but it will), that some collaborative thought on making this feature work nicely would be great! cheers, -Carter On Fri, Sep 20, 2013 at 6:05 PM, John Lato <jwlato(a)gmail.com> wrote: > @carter you're completely correct, typed template haskell would be very > nice for this. > > I think something like asStatic would be fine. It would be slightly > annoying to not be able to use numeric literals, but it seems like a good > first step at any rate. > > It would probably be possible to generate a Static value at runtime via > the ghc api. But perhaps not, I haven't played with the typed template > haskell enough to know. > > As to constructions like Static (IORef Int), that seems to capture the > semantics of a global IORef, maybe it could be useful for that sort of > application? > On Sep 20, 2013 3:19 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> > wrote: > >> @John, thats actually close to the sort of near term proposal i've been >> thinking of too! >> >> We could probably make it nicer by using the new typed template haskell >> (which geoff was/is also working on!). >> http://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal >> >> With typed template haskell, couldn't we have something like >> >> asStatic :: alpha -> TExp (Static alpha), >> >> where asStatic is the only way to introduce terms with a type (Static >> alpha)? (ie: we could only introduce static values that are closed, at Th >> time, which would also prevent us from construction a value of type (Static >> alpha) at runtime?) >> >> I think that would be enough to introduce the right compile time Static >> Data property. That would also probably capture the right notion of static >> for a number of other uses cases (I think. Probably would need a type class >> constraint on alpha, to rule out crazy things like Static (IORef Int) or >> the like ). >> >> we'd probably need to also have a fromStatic :: Static a -> a, too. >> >> But you're absolutely right, with a teeny bit of work, we could have at >> least a near term work around like that. Theres probably some subtlties i'm >> overlooking though >> >> >> >> >> >> >> On Fri, Sep 20, 2013 at 2:09 PM, John Lato <jwlato(a)gmail.com> wrote: >> >>> I think Geoffrey's suggestion is workable, but I wouldn't like it so >>> much. The difficulty is that if you aren't aware of it, it's possible to >>> build up a large system that you discover is unworkable the first time you >>> try to compile it. >>> >>> In that sense it's not too different from Template Haskell staging >>> restrictions, which IIRC exist to deal with exactly this problem. >>> >>> As the necessity of compile-time constants has shown up at least twice, >>> a more principled solution is worth investigating. >>> >>> In the meantime, a horrible hack would be something like: >>> >>> newtype CStatic v = CStatic ExpQ >>> instance Num a => Num ( CStatic a) where >>> fromInteger x = [| x |] >>> >>> and then the value could be spliced at the call site. Staging >>> restrictions would ensure it's available at compile time. I guess the >>> instance decl needs Lift too. >>> >>> Downsides are general hideous-ness, misleading error messages, and the >>> necessity for compiling with template haskell. But you'd get an error if s >>> value isn't a compile-time constant. (Please don't put this in ghc, but >>> it's not so bad as a separate lib). >>> >>> John L. >>> On Sep 19, 2013 3:44 PM, "Geoffrey Mainland" <mainland(a)apeiron.net> >>> wrote: >>> >>>> If you pass a constant, unboxed value to a primop, I assume GHC won't >>>> ever bind the argument to a value. So although we have no way to enforce >>>> "static const argument" in the type system, if this is a valuable (and >>>> experts-only?) operation, I'm not sure it matters that much if the user >>>> gets an error at code-generation time complaining about non-const >>>> arguments. >>>> >>>> Another way to look at it: if we wait until someone enhances the type >>>> system to support the notion of static arguments, we will likely never >>>> have a bit shuffle primitive. >>>> >>>> The other option would be to fall back on a different implementation if >>>> we saw a non-constant argument. I think that would actually be worse >>>> than erroring out, but I'm sure others would disagree. >>>> >>>> Geoff >>>> >>>> On 09/19/2013 11:42 AM, Carter Schonwald wrote: >>>> > tldr; we can't express / expose the LLVM shuffleVector intrinsic in a >>>> > type safe way that will correctly interact with the static argument >>>> > requirement for associated code generation. >>>> > >>>> > >>>> > >>>> > >>>> > On Thu, Sep 19, 2013 at 12:40 AM, Carter Schonwald >>>> > <carter.schonwald(a)gmail.com <mailto:carter.schonwald@gmail.com>> >>>> wrote: >>>> > >>>> > yup, i hit a gap in what we can currently express in haskell >>>> > types. We don't have a way of expressing static data! I actually >>>> > put ticket on trac noting >>>> > this. http://ghc.haskell.org/trac/ghc/ticket/8107 >>>> > (note that when i was initially writing the ticket, i incorrectly >>>> > thought the int# arg to ghc's prefetch was the locality level >>>> > rather than a byte offset) >>>> > >>>> > Currently GHC has no way of expressing "this argument needs to be >>>> > a static compile/codegen time constant" in surface haskell or >>>> > core! This means we could at best provide a suite of special cased >>>> > operations. (eg: we could provide the inter-lane shuffle for >>>> > swapping halves of YMM registers, and the miniature analogue for >>>> > XMM), but that would really be missing the point: being able to >>>> > write complex algorithms that can work completely in registers! >>>> > >>>> > the vast majority of the simd shuffle operations have certain >>>> > arguments that need to be compile time static values that are used >>>> > in the actual code generation. The llvm data model doesn't express >>>> > this constraint. This invariant failure was also hit internally >>>> > recently via a bug in how GHC generated code for llvm's >>>> > memcopy! http://ghc.haskell.org/trac/ghc/ticket/8131 >>>> > >>>> > If we could express llvm'sshuffleVector >>>> > <http://llvm.org/docs/LangRef.html#shufflevector-instruction> >>>> > intrinsic in a type safe way, then we could express any of them. I >>>> > would be over the moon if we could expose an operation like >>>> > shuffleVector, but I dont' think GHC currently can express it in a >>>> > type safe way that won't make LLVM vomit. >>>> > >>>> > I want simd shuffle, but i don't see how to give the fully general >>>> > shuffle operations in type safe ways with ghc currently. We need >>>> > to add support for some notion of static data first! If theres a >>>> > way, i'm all for it, but I don't see such a way. >>>> > >>>> > I hope that answers your question. that seems to be a deep enough >>>> > issue that theres no way to resolve it with simple engineering in >>>> > the next few weeks. >>>> > >>>> > -Carter >>>> > >>>> > >>>> > >>>> > >>>> > On Wed, Sep 18, 2013 at 9:41 PM, Geoffrey Mainland >>>> > <mainland(a)apeiron.net <mailto:mainland@apeiron.net>> wrote: >>>> > >>>> > On 09/18/2013 04:49 PM, Carter Schonwald wrote: >>>> > > I've some thoughts on how to have a better solution, but >>>> > they are >>>> > > feasible only on a time scale suitable for 7.10, and not for >>>> > 7.8. >>>> > > >>>> > > a hacky solution we could do for 7.8 perhaps is have a >>>> > warning that >>>> > > works as follows: >>>> > > >>>> > > either >>>> > > a) >>>> > > throw a warning on functions that use the SIMD primops, if >>>> that >>>> > > function is being exported by a module, and that function >>>> > isn't marked >>>> > > NOINLINE ? Theres probably a few subtleties to it, and this >>>> > is just a >>>> > > naive idea >>>> > That wouldn't inform the consumers of a module. And for a >>>> > library like >>>> > vector, we definitely want to export unfoldings for code that >>>> > contains >>>> > SIMD primops. That's the only way to get good code out of the >>>> > library! >>>> > > b) somehow put both the -fllvm and -fasm core for inlineable >>>> > functions >>>> > > in the .hi file? (this one prevents the most problems, but >>>> > is probably >>>> > > the most complex work around we could do). >>>> > The problem being that there *is* no -fasm code...because the >>>> NCG >>>> > doesn't support SIMD operations. Unless we added a mechanism >>>> > to have two >>>> > completely different, but simultaneous, definitions for a >>>> > function, one >>>> > for -fasm and one for -fllvm. But that would be a lot of work >>>> and >>>> > couldn't be done for 7.8. >>>> > > >>>> > > >>>> > > its worth noting that the LLVM simd in 7.8, either way, >>>> > won't support >>>> > > simd shuffles, which will seriously curtail its general >>>> utility, >>>> > > either way. >>>> > >>>> > You told me you would send me example use cases, type >>>> > signatures, etc. >>>> > Did I miss an email? If this is very important to you, was >>>> there a >>>> > particular difficulty you had implementing these primops? >>>> > >>>> > > On Wed, Sep 18, 2013 at 4:22 PM, Simon Marlow >>>> > <marlowsd(a)gmail.com <mailto:marlowsd@gmail.com> >>>> > > <mailto:marlowsd@gmail.com <mailto:marlowsd@gmail.com>>> >>>> wrote: >>>> > > >>>> > > On 18/09/13 20:01, Geoffrey Mainland wrote: >>>> > > >>>> > > We did discuss this, but you may not have been >>>> present. >>>> > > >>>> > > If LLVM-only primops show up in a non-LLVM codegen, >>>> > a "sorry" >>>> > > error is >>>> > > reported telling the user that they need to compile >>>> with >>>> > > "-fllvm". Yes, >>>> > > this is not a fantastic solution. Options I see: >>>> > > >>>> > > 1) Live with the error message. >>>> > > 2) Remove all SIMD support until the NCG catches up. >>>> > > 3) Figure out a mechanism that avoids inlining any >>>> > code containing >>>> > > LLVM-only primops when we're not using the LLVM back >>>> > end. >>>> > > >>>> > > Maybe you can think of another solution? >>>> > > >>>> > > >>>> > > Those are the three unsatisfactory solutions that I know >>>> > of. Even >>>> > > if we did (3), the user still wants to know when that is >>>> > happening >>>> > > because they're getting less good code, so you'd want a >>>> > warning. >>>> > > >>>> > > One thing we might try to do is automatically enable >>>> > -fllvm when >>>> > > the compilation would otherwise fail. If LLVM isn't >>>> > installed and >>>> > > the compilation still fails, it's no worse than failing >>>> > to compile >>>> > > the module with the sorry error. >>>> > > >>>> > > Simon >>>> > > >>>> > > >>>> > > >>>> > > Geoff >>>> > > >>>> > > On 09/18/2013 02:54 PM, Simon Marlow wrote: >>>> > > >>>> > > This is slightly problematic. What if we have a >>>> > wonderful >>>> > > SIMD-enabled vector library that we compile with >>>> > -fllvm, >>>> > > and then use >>>> > > it in a program that isn't compiled with -fllvm, >>>> > and some >>>> > > of the >>>> > > wonderful SIMD-enabled functions get inlined? >>>> > Presumably >>>> > > we get a >>>> > > panic in the NCG. >>>> > > >>>> > > Did we discuss this before? I have vague >>>> > memories, but >>>> > > don't remember >>>> > > what the outcome was. >>>> > > >>>> > > Cheers, >>>> > > Simon >>>> > > >>>> > > On 12/09/13 03:10, Geoffrey Mainland wrote: >>>> > > >>>> > > We support compiling some code with -fllvm >>>> > and some >>>> > > not in the same >>>> > > executable. Otherwise how could users of the >>>> > Haskell >>>> > > Platform link their >>>> > > -fllvm-compiled code with >>>> > native-codegen-compiled >>>> > > libraries like >>>> > > base, etc.? >>>> > > >>>> > > In other words, the LLVM and native back >>>> > ends use the >>>> > > same calling >>>> > > convention. With my SIMD work, they still >>>> > use the same >>>> > > calling >>>> > > conventions, but the native codegen can >>>> > never generate >>>> > > code that uses >>>> > > SIMD instructions. >>>> > > >>>> > > Geoff >>>> > > >>>> > > On 09/11/2013 10:03 PM, Johan Tibell wrote: >>>> > > >>>> > > OK. But that doesn't create a problem >>>> > for the code >>>> > > we output with the >>>> > > LLVM backend, no? Or do we support >>>> > compiling some >>>> > > code with -fllvm and >>>> > > some not in the same executable? >>>> > > >>>> > > >>>> > > On Wed, Sep 11, 2013 at 6:56 PM, >>>> > Geoffrey Mainland >>>> > > <mainland(a)apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>>>> wrote: >>>> > > >>>> > > We definitely have interop >>>> between the >>>> > > native codegen and the LLVM >>>> > > back >>>> > > end now. Otherwise anyone who >>>> > wanted to use >>>> > > the LLVM back end >>>> > > would have >>>> > > to build GHC themselves. Interop >>>> > means that >>>> > > users can install the >>>> > > Haskell Platform and still use >>>> > -fllvm when >>>> > > it makes a performance >>>> > > difference. >>>> > > >>>> > > Geoff >>>> > > >>>> > > On 09/11/2013 07:59 PM, Johan >>>> > Tibell wrote: >>>> > > > Do nothing different than you're >>>> > doing for >>>> > > 7.8, we can sort >>>> > > it out >>>> > > > later. Just put a comment on the >>>> > primops >>>> > > saying they're >>>> > > LLVM-only. See >>>> > > > e.g. >>>> > > > >>>> > > > >>>> > > > >>>> > > >>>> > > >>>> > >>>> https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181 >>>> > > > >>>> > > > for an example how to add docs >>>> > to primops. >>>> > > > >>>> > > > I don't think we need interop >>>> > between the >>>> > > native and the LLVM >>>> > > > backends. We don't have that now >>>> > do we >>>> > > (i.e. they use different >>>> > > > calling conventions). >>>> > > > >>>> > > > >>>> > > > >>>> > > > On Wed, Sep 11, 2013 at 4:51 PM, >>>> > Geoffrey >>>> > > Mainland >>>> > > > <mainland(a)apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>>> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>>>>> >>>> > > wrote: >>>> > > > >>>> > > > On 09/11/2013 07:44 PM, >>>> > Johan Tibell >>>> > > wrote: >>>> > > > > On Wed, Sep 11, 2013 at >>>> > 4:40 PM, >>>> > > Geoffrey Mainland >>>> > > > <mainland(a)apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>>> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net> >>>> > > <mailto:mainland@apeiron.net >>>> > <mailto:mainland@apeiron.net>>>>> >>>> > > wrote: >>>> > > > > > Do you mean we need a >>>> > reasonable >>>> > > emulation of the SIMD >>>> > > primops for >>>> > > > > > the native codegen? >>>> > > > > >>>> > > > > Yes. Reasonable in the >>>> > sense that it >>>> > > computes the right >>>> > > result. >>>> > > > I can >>>> > > > > see that some code might >>>> > still want >>>> > > to #ifdef (if the >>>> > > fallback isn't >>>> > > > > fast enough). >>>> > > > >>>> > > > Two implications of this >>>> > requirement: >>>> > > > >>>> > > > 1) There will not be SIMD in >>>> > 7.8. I >>>> > > just don't have the >>>> > > time. In fact, >>>> > > > what SIMD support is there >>>> > already >>>> > > will have to be >>>> > > removed if we >>>> > > > cannot >>>> > > > live with LLVM-only SIMD >>>> > primops. >>>> > > > >>>> > > > 2) If we also require >>>> > interop between >>>> > > the LLVM back-end and >>>> > > the native >>>> > > > codegen, then we cannot pass >>>> > any SIMD >>>> > > vectors in >>>> > > registers---they all >>>> > > > must be passed on the stack. >>>> > > > >>>> > > > My plan, as discussed with >>>> > Simon PJ, >>>> > > is to not support SIMD >>>> > > primops at >>>> > > > all with the native codegen. >>>> > If there >>>> > > is a strong feeling >>>> > > that >>>> > > > this *is >>>> > > > not* the way to go, the I >>>> > need to know >>>> > > ASAP. >>>> > > > >>>> > > > Geoff >>>> > > > >>>> > > > >>>> > > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>> >>> >>

2 2

Fixing 8266: How do I get a list of all dist-install/build directories?
by Christiaan Baaij 21 Sep '13

21 Sep '13

Hello everyone, I'm trying to write a patch for #8266. Here's what I have so far: https://gist.github.com/christiaanb/6648192 It changes the name of the dynamic library to a relative path instead of an absolute one. However, now I'm getting an error while building the DPH packages (probably due to the use of TH): Loading package vector-0.9.1 ... <command line>: can't load .so/.DLL for: /Users/christiaan/Documents/devel/ghc/libraries/vector/dist-install/build/libHSvector-0.9.1-ghc7.7.20130918.dylib (dlopen(/Users/christiaan/Documents/devel/ghc/libraries/vector/dist-install/build/libHSvector-0.9.1-ghc7.7.20130918.dylib, 9): Library not loaded: @loader_path/../primitive-0.4.0.1/libHSprimitive-0.4.0.1-ghc7.7.20130918.dylib Referenced from: /Users/christiaan/Documents/devel/ghc/libraries/vector/dist-install/build/libHSvector-0.9.1-ghc7.7.20130918.dylib Reason: image not found) Of course the problem is, is that the packages are not installed yet, so the relative paths don't make sense yet. My solution is to update rules/shell-wrapper.mk, and to add DYLD_FALLBACK_LIBRARY_PATH = <ALL_LIBRARY_BUILD_DIRS> to the inplace/bin shell wrappers. So that during building of ghc, dynlibs of all the packages can still be resolved to the place where they were build. So my question is: how do I get the list <ALL_LIBRARY_BUILD_DIRS> within the build system? Cheers, Christiaan

1 0

Re: llvm calling convention matters
by Carter Schonwald 20 Sep '13

20 Sep '13

hey all, first let me preface by saying I am in favor of breaking and updating/modernizing the GHC ABI. I just think that for a number of reasons, it doesn't make sense to do it for the 7.8 release, but rather start work on it in another month or so, so we can systematically have a better set of ABI, and keep all the code gens are first class citizens. (also work out the type system changes need to be able to correctly use SIMD shuffles, which are currently inexpressible correctly with GHC's type system. Simd Shuffles are crucial for interesting levels of SIMD performance!) the reason I don't want to make the ABI change right now is because then we'd have to wait until after llvm 3.4 gets released in like 6 months before giving them another breaking change! (OR start baking a LLVM into GHC, which is a leap we're not 100% on, though theres clear good reasons for why! ). Basically, if we make breaking changes to the ABI now (and thus have split ABI for llvm 3.4HEAD vs earlier), and then we do fixups or more breakage for 7.10, then when 7.10 rolls around (perhaps late next spring or sometime in the summer, perhaps?), the only supported llvm version for 7.10 would be LLVM HEAD / 3.5 (which won't be released till some time thereafter)! Unless we go ahead and break the 3.4 ABI to 7.10 rather than 7.8 abi (whatever that would entai, which would ). This is assuming the ~ 7-8 months between major version releases cycle that LLVM has done of late additionally, as Johan remarked today on a pending patch of mine, having operations only work on the llvm backend, and not on the native code gen is pretty problematical! see http://ghc.haskell.org/trac/ghc/ticket/8256 tl;dr : Unless we're throwing away native code gen backend next month, we probably want to actually not increase their capability gap / current ABI incompatibility right before 7.8 release. I am willing to help explore modernizing the native code gens so that they have parity with the llvm backends. Additionally, boxing ourselves in a corner where for 7.10 the only llvm with the right ABI will be llvm 3.5 seems totally unacceptable from an end users / distribution package managers standpoint, and a huge support headache for the community. I've had to help deal with the support headache of the xcode5 clang + ghc issues on OS X, A LOT, in the past 2 months, I'm not keen on deliberately creating similar support disasters for myself and others. that said: I absolutely agree that we should fix up the ABI, have a clear story for XMM, YMM, and ZMM registers, and if you've been following trac tickets at all, you'll see theres even a type system issue in properly handling the SIMD shuffles! i briefly sketch out the issue in http://ghc.haskell.org/trac/ghc/ticket/8107 (last comment) that said: i'm open to being convinced i'm wrong, and I absolutely understand your motivations for wanting it now, but I really believe that doing so right now will create a number of problems that are better off evaded to begin with cheers -Carter On Wed, Sep 11, 2013 at 5:49 PM, Geoffrey Mainland <mainland(a)cs.drexel.edu>wrote: > Hi Carter, > > On 09/06/2013 03:24 PM, Carter Tazio Schonwald wrote: > > Hey Geoff, > > > I'm leary about doing a calling convention change right before the ghc > > release (and I"m happy to elaborate more on the phone some time) 1) > > I'd rather we test the patches on llvm locally ourselves before going > > upstream 2) doing that AVX change on the calling convention now, would > > make it harder to make a more systematic exploration of calling > > convention changes post 7.8 release, because we would face either > > breaking the llvm head/3.4 changes, or having to wait till the next > > llvm release cycle (3.5?!) to upstream any more systematic > > changes. (such as adding substantially more SIMD registers to the GHC > > calling convention!) > > > > I understand your likely motivation for wanting the calling convention > > landing in the 7.8 release, namely it may eke an easy 2x perf boost in > > your stream fusion libs, i just worry that the change would ultimately > > cut off our ability to do more aggressive experimentation and > > improvements (eg more simd registers!) for ghc 7.10 over the next > > year? > > > > on an unrelated note: I will spend some time this weekend given you > > the various simd operations I want / think are valuable. the low > > hanging fruit would be figuring out a good haskell type / analogue of > > the llvm __builtin_shuffle(a,b,c) primop, because that usually should > > generate decent code. I'll work out the details of this and some other > > examples and send it your way in the next few days > > > > -Carter > > Currently, on x86-64 we pass floats, doubles, and 128-bit wide SIMD > vectors in xmm1-xmm6. I propose that we change the calling conventions > to pass 256-bit wide SIMD vectors in ymm1-ymm6 and 512-bit wide SIMD > vectors in zmm1-zmm6. I don't know why GHC doesn't use xmm0 or xmm7, as > the Linux C calling convention uses xmm0-xmm7. Simon, perhaps you know > why? I get that we only needed 6 registers originally, F1-F4, D1-D2), > but why count from one rather than zero? > > On x86-32, we pass floats, double, and all SIMD vectors on the stack. I > propose that we pass 128-bit wide SIMD vectors in xmm0-xmm2, and make > analogous arrangements for 256- and 512-bit SIMD vectors. We will still > pass floats and doubles on the stack. This matches the Linux x86 32-bit > C calling convention. > > I think these are fairly conservative changes. I also don't think we > should be afraid of revising the calling convention for GHC 7.10. Surely > the LLVM folks won't be upset if we send them one set of patches a year > instead of one set of patches every two years. > > Geoff > >

5 22