- ghc-devs - Haskell.org

Re: [commit: ghc] master: Simplify Control Flow Optimisations Cmm pass (99c3ed8)
by Simon Marlow 13 Feb '14

13 Feb '14

Hi Jan - I'm not sure I agree that the case you removed was superfluous. There are two cases we want to replace a branch to a block with the contents of the block itself: (1) when the block is referenced only once (2) when the block is small enough The case you removed was (2). Now, as it happens right now (2) was not doing anything interesting because our definition of "small enough" is "a single branch", but it could in theory be more liberal. There used to be a function called "okToDuplicate" (removed in one of your earlier patches) that made this decision, and our intention was to experiment with extending this to allow duplication of code in some cases. Shortcutting a branch might be ok if the block only contains a single instruction, for example, because then the total number of instructions executed is the same (and there are one fewer branches). Cheers, Simon On 01/02/2014 19:04, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/99c3ed81ac53629771b00a0abbe37c989… > >> --------------------------------------------------------------- > > commit 99c3ed81ac53629771b00a0abbe37c989ea45cd6 > Author: Jan Stolarek <jan.stolarek(a)p.lodz.pl> > Date: Sat Feb 1 18:00:48 2014 +0100 > > Simplify Control Flow Optimisations Cmm pass > > It turns out that one of the cases in the optimization pass was > a special case of another. I remove that specialization since it > does not have impact on compilation time, and the resulting Cmm > is identical. > > >> --------------------------------------------------------------- > > 99c3ed81ac53629771b00a0abbe37c989ea45cd6 > compiler/cmm/CmmContFlowOpt.hs | 37 +++++++++---------------------------- > 1 file changed, 9 insertions(+), 28 deletions(-) > > diff --git a/compiler/cmm/CmmContFlowOpt.hs b/compiler/cmm/CmmContFlowOpt.hs > index 52b95a9..4b8ce6f 100644 > --- a/compiler/cmm/CmmContFlowOpt.hs > +++ b/compiler/cmm/CmmContFlowOpt.hs > @@ -46,25 +46,20 @@ import Prelude hiding (succ, unzip, zip) > -- Note [Control-flow optimisations] > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- > --- This optimisation does four things: > +-- This optimisation does three things: > -- > -- - If a block finishes in an unconditonal branch to another block > -- and that is the only jump to that block we concatenate the > -- destination block at the end of the current one. > -- > --- - If a block finishes in an unconditional branch, we may be able > --- to shortcut the destination block. > --- > -- - If a block finishes in a call whose continuation block is a > -- goto, then we can shortcut the destination, making the > -- continuation block the destination of the goto - but see Note > -- [Shortcut call returns]. > -- > --- - For block finishing in conditional branch we try to invert the > --- condition and shortcut destination of alternatives. > --- > -- - For any block that is not a call we try to shortcut the > --- destination(s). > +-- destination(s). Additionally, if a block ends with a > +-- conditional branch we try to invert the condition. > -- > -- Blocks are processed using postorder DFS traversal. A side effect > -- of determining traversal order with a graph search is elimination > @@ -204,11 +199,8 @@ blockConcat splitting_procs g@CmmGraph { g_entry = entry_id } > -- (2) remove b' from the map of blocks > -- (3) remove information about b' from predecessors map > -- > - -- This guard must be first so that we always eliminate blocks that have > - -- only one predecessor. If we had a target block that is both > - -- shorcutable and has only one predecessor and attempted to shortcut it > - -- first we would make that block unreachable but would not remove it > - -- from the graph. > + -- Since we know that the block has only one predecessor we call > + -- mapDelete directly instead of calling decPreds. > -- > -- Note that we always maintain an up-to-date list of predecessors, so > -- we can ignore the contents of shortcut_map > @@ -221,20 +213,6 @@ blockConcat splitting_procs g@CmmGraph { g_entry = entry_id } > , mapDelete b' backEdges ) > > -- If: > - -- (1) current block ends with unconditional branch to b' and > - -- (2) we can shortcut block b' > - -- Then: > - -- (1) concatenate b' at the end of current block, effectively > - -- changing target of uncondtional jump from b' to dest > - -- (2) increase number of predecessors of dest by 1 > - -- (3) decrease number of predecessors of b' by 1 > - | CmmBranch b' <- last > - , Just blk' <- mapLookup b' blocks > - , Just dest <- canShortcut blk' > - = ( mapInsert bid (splice head blk') blocks, shortcut_map, > - decPreds b' $ incPreds dest backEdges ) > - > - -- If: > -- (1) we are splitting proc points (see Note > -- [Shortcut call returns and proc-points]) and > -- (2) current block is a CmmCall or CmmForeignCall with > @@ -263,7 +241,10 @@ blockConcat splitting_procs g@CmmGraph { g_entry = entry_id } > -- conditional > -- (2) attempt to shortcut all destination blocks > -- (3) if new successors of a block are different from the old ones > - -- we update the of predecessors accordingly > + -- update the of predecessors accordingly > + -- > + -- A special case of this is a situation when a block ends with an > + -- unconditional jump to a block that can be shortcut. > | Nothing <- callContinuation_maybe last > = let oldSuccs = successors last > newSuccs = successors swapcond_last > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

make binary-dist on Solaris 10.
by Karel Gardas 10 Feb '14

10 Feb '14

Folks, I'm trying to kind of resurrect Solaris 10 support. Got to `make binary-dist' already but now this fails with: cd bindistprep && "/usr/sfw/bin/gtar" hcf - -T ../bindist-list | bzip2 -c > ../bindistprep/ghc-7.8.20140130-i386-unknown-solaris2.tar.bz2 /usr/sfw/bin/gtar: ghc-7.8.20140130/compiler/stage2/doc: Cannot stat: No such file or directory /usr/sfw/bin/gtar: Error exit delayed from previous errors mv bindistprep/*.tar.bz2 . I'd just like to ask here, any idea what tool is responsible for generating this doc content in compiler's stage2 dir? My idea is that some tool(s) is missing on Solaris 10, configure detects this, general build is fine then, but bindist counts with the `doc' dir populated. So just let me know into what direction I shall look... Thanks! Karel

2 2

[PATCH 2/2] use detected GNU sed on expression where Solaris' fails.
by Karel Gardas 09 Feb '14

09 Feb '14

We set SED make variable to configure detected GNU sed command for quite some time now, but surprisingly it is not used in other makefiles. Anyway, this patch fixes a real issue on Solaris 10 where distributed Sun/Oracle sed is not able to cope with required expression, but GNU sed is. The patch is minimal to lower the risk of breakage, but the other approach of fixing all occurrences of `sed' to `$(SED)' is of course also possible. --- rules/build-dependencies.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/build-dependencies.mk b/rules/build-dependencies.mk index 79350c0..896efa8 100644 --- a/rules/build-dependencies.mk +++ b/rules/build-dependencies.mk @@ -53,7 +53,7 @@ endif # Foo.dyn_o Foo.o : Foo.hs # lines, and create corresponding hi-rule lines # <dollar>(eval <dollar>(call hi-rule,Foo.dyn_hi Foo.hi : %hi: %o Foo.hs)) - sed '/hs$$$$/ p ; \ + $(SED) '/hs$$$$/ p ; \ /hs$$$$/ s/o /hi /g ; \ /hs$$$$/ s/:/ : %hi: %o / ; \ /hs$$$$/ s/^/$$$$(eval $$$$(call hi-rule,/ ; \ -- 1.8.1.4

1 0

[PATCH 1/2] add --with-ar and --with-ranlib configure parameters
by Karel Gardas 09 Feb '14

09 Feb '14

Both --with-ar and --with-ranlib are usable on non-GNU/Linux systems where GNU tools are usually installed (or possible to install), but not into standard location nor with standard name. Tested on Solaris 10. --- configure.ac | 15 +++++++++++++++ mk/config.mk.in | 1 + 2 files changed, 16 insertions(+) diff --git a/configure.ac b/configure.ac index e7fbc7f..244fcc0 100644 --- a/configure.ac +++ b/configure.ac @@ -486,6 +486,21 @@ FP_ARG_WITH_PATH_GNU_PROG([NM], [nm], [nm]) NmCmd="$NM" AC_SUBST([NmCmd]) +dnl ** Which ar to use? +dnl -------------------------------------------------------------- +FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar]) +ArCmd="$AR" +fp_prog_ar="$AR" +AC_SUBST([ArCmd]) + +dnl ** Which ranlib to use? +dnl -------------------------------------------------------------- +FP_ARG_WITH_PATH_GNU_PROG([RANLIB], [ranlib], [ranlib]) +RanlibCmd="$RANLIB" +RANLIB="$RanlibCmd" +AC_SUBST([RanlibCmd]) + + # Note: we may not have objdump on OS X, and we only need it on Windows (for DLL checks) case $HostOS_CPP in cygwin32|mingw32) diff --git a/mk/config.mk.in b/mk/config.mk.in index b3d6995..8c0eb49 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -650,6 +650,7 @@ DTRACE = @DtraceCmd@ LD = @LdCmd@ NM = @NmCmd@ +AR = @ArCmd@ OBJDUMP = @ObjdumpCmd@ LLC = @LlcCmd@ -- 1.8.1.4

1 0

[PATCH] fix compilation on Solaris 10 with GNU C 3.4.3
by Karel Gardas 09 Feb '14

09 Feb '14

This patch fixes compilation on Solaris 10 platform which provides GNU C 3.4.3 by default by removing unsupported -ftree-vectorize option. This may penalize Solaris 11, where GNU C 4.6.2 is provided but current cabal does not support OSes version detection and Solaris 10 is still supported (by Oracle) and will be at least till 2021 so let's support it too. --- primitive.cabal | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/primitive.cabal b/primitive.cabal index b819e03..666a8f2 100644 --- a/primitive.cabal +++ b/primitive.cabal @@ -44,7 +44,9 @@ Library Install-Includes: primitive-memops.h includes: primitive-memops.h c-sources: cbits/primitive-memops.c - cc-options: -O3 -ftree-vectorize -fomit-frame-pointer -Wall + cc-options: -O3 -fomit-frame-pointer -Wall + if !os(solaris) + cc-options: -ftree-vectorize if arch(i386) || arch(x86_64) cc-options: -msse2 -- 1.8.1.4

1 0

Nightlies
by Mateusz Kowalczyk 08 Feb '14

08 Feb '14

Hi all, I'd just like to query the status of the nightly builds. Is anything happening in that area? [1] is right on the front page of the GHC Trac even though no builds were ran for ~5 months. Perhaps it should be moved out of the way if there's no plan to resume these in the near future. Does anything specific need doing to get these to run again? [1]: https://ghc.haskell.org/trac/ghc/wiki/Builder -- Mateusz K.

10 22

Support for glibc 2.12 in 7.8 RC2
by Rob Stewart 08 Feb '14

08 Feb '14

Hi, The 7.8 RC1 status page [1] states RC1 requires glibc 2.15, and that RC2 will support glibc 2.13 to target Debian 7. CentOS 6 packages glibc 2.12 and this will be the glibc version in the CentOS 6 lifetime. Is there a possibility of stretching lower bounded support in RC2 down to glibc 2.12? This would allow all CentOS users using any of the 6.* releases to use 7.8, I think. [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC1 -- Rob

3 2

GHC iOS 7.8.1 RC1 for Device & Simulator
by Luke Iannini 07 Feb '14

07 Feb '14

Hi folks, RC builds of GHC iOS are now ready for devices and the iOS simulator. https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-device… https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8-rc1-simula… You'll find complete instructions on their usage here, including compiling cabal packages: https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md Please let me know how it goes! Cheers Luke

2 1

Re: [commit: ghc] master: Mention that MR is off by default in GHCi in documentation (5bda0d0)
by Gabor Greif 06 Feb '14

06 Feb '14

It would be probably clearer to say "Since GHC 7.8.1, the monomorphism restriction is switched off by default in GHCi." This makes the awkward double-negation feeling go away. What do others think? Cheers, Gabor On 2/6/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/5bda0d08d8fec86433917b65a93836d23… > >>--------------------------------------------------------------- > > commit 5bda0d08d8fec86433917b65a93836d2372a5b5c > Author: Krzysztof Gogolewski <krz.gogolewski(a)gmail.com> > Date: Wed Feb 5 20:40:13 2014 +0100 > > Mention that MR is off by default in GHCi in documentation > > >>--------------------------------------------------------------- > > 5bda0d08d8fec86433917b65a93836d2372a5b5c > docs/users_guide/glasgow_exts.xml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/docs/users_guide/glasgow_exts.xml > b/docs/users_guide/glasgow_exts.xml > index a3913cc..1564f38 100644 > --- a/docs/users_guide/glasgow_exts.xml > +++ b/docs/users_guide/glasgow_exts.xml > @@ -7862,7 +7862,8 @@ scope over the methods defined in the > <literal>where</literal> part. For exampl > 4.5.5</ulink> > of the Haskell Report) > can be completely switched off by > -<option>-XNoMonomorphismRestriction</option>. > +<option>-XNoMonomorphismRestriction</option>. Since GHC 7.8.1, it is > +switched off by default in GHCi. > </para> > </sect3> > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

4 3

Bad news: apparent bug in casMutVar going back to 7.2
by Ryan Newton 06 Feb '14

06 Feb '14

I commented on the commit here: https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b The problem is that our "cas" routine in SMP.h is similar to the C compiler intrinsic __sync_val_compare_and_swap, in that it returns the old value. But it seems we cannot use a comparison against that old value to determine whether or not the CAS succeeded. (I believe the CAS may fail due to contention, but the old value may happen to look like our old value.) Unfortunately, this didn't occur to me until it started causing bugs [1] [2]. Fixing casMutVar# fixes these bugs. However, the way I'm currently fixing CAS in the "atomic-primops" package is by using __sync_bool_compare_and_swap: https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256d… What is the best fix for GHC itself? Would it be ok for GHC to include a C compiler intrinsic like __sync_val_compare_and_swap? Otherwise we need another big ifdbef'd function like "cas" in SMP.h that has the architecture-specific inline asm across all architectures. I can write the x86 one, but I'm not eager to try the others. Best, -Ryan [1] https://github.com/iu-parfunc/lvars/issues/70 [2] https://github.com/rrnewton/haskell-lockfree/issues/15

4 16