March 2017 - ghc-devs

What should and should not be marked has_side_effects?
by David Feuer 11 Mar '17

11 Mar '17

Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says > A primop "has_side_effects" if it has some *write* effect, visible > elsewhere > > - writing to the world (I/O) > - writing to a mutable data structure (writeIORef) > - throwing a synchronous Haskell exception > > [...] > > * NB3: *Read* effects (like reading an IORef) don't count here, > > because it doesn't matter if we don't do them, or do them more than > once. *Sequencing* is maintained by the data dependency of the state > token. But this does not actually seem to match what goes on in primops.txt.pp. The following, among many other seemingly read-only operations, have has_side_effects = True: readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#, unsafeThawArray#, tryReadMVar#, deRefWeak# So what's the correct story? Do we want to change the note, or change the reality? The reason I happen to be looking at this is that I think the current arrangement allows us to define unsafeInterleaveIO in a particularly simple fashion: unsafeInterleaveIO = pure . unsafePerformIO but that's only safe as long as the interleaved IO won't float out and get performed before it's forced by normal IO. But the unsafeInterleaveIO story seems much less important, in the grand scheme of things, than making everything else run fast. If indeed it's otherwise safe to mark these read-only ops has_side_effects=False, then I imagine we probably should do that. David Feuer

2 1

New commits
by Simon Peyton Jones 10 Mar '17

10 Mar '17

Edward, Ben, others I have just pushed a patch series 2209d5e6 Comments only 4eeb3273 Drop redundant import 2d3cb34a Define TcSimplify.simplifyTopImplic and use it af6ed4a6 Fix constraint simplification in rules 48d1866e Improve error messages for skolems 7e96526a Fix TcSimplify.decideQuantification for kind variables bc0f3abd Deal with JoinIds before void types 900cfdc2 Do not generate a data-con wrapper for !Int# Issues: * bkpcabal03 is failing... I don't see how it can possibly have anything to do with me, so I've pushed anyway. Edward, might you look? * I get these stat failures - all improvements perf/compiler/T13035.run T13035 [stat too good] (normal) perf/compiler/T12425.run T12425 [stat too good] (optasm) perf/compiler/T9675.run T9675 [stat too good] (optasm) perf/space_leaks/T4029.run T4029 [stat too good] (ghci) perf/should_run/T10359.run T10359 [stat too good] (normal) perf/compiler/T1969.run T1969 [stat too good] (normal) Some of them are from before (I reported this and suggested re-centreing the numbers), but the last two are new, I think. Hurrah! Ben: might you look? Sorry for playing a bit fast and loose, but I'm out of time, and there are bug-fixes in here. Thanks Simon bkpcabal03 simonpj@cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$ make bkpcabal03 rm -f -r tmp.d inst dist Setup make -s --no-print-directory clean '/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-pkg' init tmp.d '/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' -v0 --make Setup cp bkpcabal03.cabal.in1 bkpcabal03.cabal # typecheck asig1 (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "asig1" asig1) (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build) (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 copy) (cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 register) # typecheck asig2 (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "asig2" asig2) (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build) (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 copy) (cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 register) # typecheck top-level '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "toplevel" bkpcabal03 ! '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: Foo Mod.hs:4:5: error: Variable not in scope: g :: Int # modify mixins cp bkpcabal03.cabal.in2 bkpcabal03.cabal # retypecheck top-level '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "toplevel" bkpcabal03 '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build <no location info>: warning: [-Wmissing-home-modules] Modules are not listed in command line: Foo simonpj@cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$ dirs ~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03 ~/5builds/HEAD-5 ~/code/HEAD-5 simonpj@cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$

2 1

Windows
by Simon Peyton Jones 10 Mar '17

10 Mar '17

Windows build is working again....thank you! (To be fair, I'm still building stage2, so have not tried the testsuite yet, but I live in hope.) Simon

1 0

FW: GHC on Windows 10 15019+
by Simon Peyton Jones 10 Mar '17

10 Mar '17

Phyx and friends: does this ring a bell? Do we have a ticket? -----Original Message----- From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of J. Garrett Morris Sent: 09 March 2017 17:54 To: GHC users <glasgow-haskell-users(a)haskell.org> Subject: GHC on Windows 10 15019+ Hi y'all, I've recently run into a problem using released version of GHC on Windows 10, builds 15019 and later. The problem seems to be an incompatibility with Mingw64---builds fail calling realgcc.exe with vaguely incomprehensible error messages (Program failed to start with error 0xc0000142). Replacing the packaged version of Mingw64 with a more recent build (from Msys2, say) restores functioning, but no longer works if there are spaces in the path to GHC. I've observed this on three different machines, so I don't think it's just a configuration oddity. Has anyone else encountered similar problems, or can anyone else verify? If so, it might be worth repackaging at least the latest released version with a more recent Mingw64. /g -- Prosperum ac felix scelus virtus vocatur -- Seneca The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

2 1

Windows build failing in a new way
by Simon Peyton Jones 10 Mar '17

10 Mar '17

My windows build is more broken than usual. I can't even build a GHC. Please, could someone fix this? I'm getting desperate. Simon libtool: compile: C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -fexceptions -MT src/x86/ffi64.lo -MMD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -o src/x86/ffi64.o depbase=`echo src/x86/unix64.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ./libtool --mode=compile C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD -MP -MF $depbase.Tpo -c -o src/x86/unix64.lo ../src/x86/unix64.S &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD -MP -MF src/x86/.deps/unix64.Tpo -c ../src/x86/unix64.S -o src/x86/unix64.o ../src/x86/unix64.S: Assembler messages: ../src/x86/unix64.S:45: Error: junk at end of line, first unrecognized character is `f' ../src/x86/unix64.S:204: Error: junk at end of line, first unrecognized character is `f' ../src/x86/unix64.S:208: Error: junk at end of line, first unrecognized character is `f' ../src/x86/unix64.S:326: Error: junk at end of line, first unrecognized character is `f' ../src/x86/unix64.S:334: Error: junk at end of line, first unrecognized character is `,' make[5]: *** [Makefile:1335: src/x86/unix64.lo] Error 1 make[5]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys' make[4]: *** [Makefile:1596: all-recursive] Error 1 make[4]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys' make[3]: *** [Makefile:730: all] Error 2 make[3]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys' make[2]: *** [Makefile:608: all-all] Error 2 rts/ghc.mk:494: rts/dist/build/.depend-v-l-debug-thr-thr_debug-thr_l.c_asm: No such file or directory make[1]: *** [libffi/ghc.mk:115: libffi/stamp.ffi.static.build] Error 2 make: *** [Makefile:127: all] Error 2 /c/code/HEAD$

4 10

RE: [commit: ghc] master: Add a comment to the mapFB rules (665cefe)
by Simon Peyton Jones 09 Mar '17

09 Mar '17

| +-- The "mapFB" rule optimises compositions of map and | +-- the "mapFB/id" rule get rids of 'map id' calls. | +-- (Any similarity to the Functor laws for [] is expected.) Yes, obviously. But did you have a use-case, or did you just to this on principle? If you don't have this rule what goes wrong. You must have had a proximate reason for adding it. Oh. And I've just realised that mapFB c id will turn into \x y. c x y as soon as you inline mapFB. So why do you need a RULE to do that? Why not leave it for the inliner? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 09 March 2017 15:14 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Add a comment to the mapFB rules | (665cefe) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F665cefe80d112ed2e4fb9617d277a1466 | e83f9bd%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C8854d69a18b4459 | e528808d466feef08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466 | 92510080066&sdata=IR%2BftPvaSs2xZa74FEWe67ynoP6bgLKOExK7jtPe4Yg%3D&res | erved=0 | | >--------------------------------------------------------------- | | commit 665cefe80d112ed2e4fb9617d277a1466e83f9bd | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Thu Mar 9 16:13:08 2017 +0100 | | Add a comment to the mapFB rules | | to amend 2fa44217c1d9722227297eefb0d6c6aed7e128ca. | | | >--------------------------------------------------------------- | | 665cefe80d112ed2e4fb9617d277a1466e83f9bd | libraries/base/GHC/Base.hs | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs | index 6f9d454..a678c22 100644 | --- a/libraries/base/GHC/Base.hs | +++ b/libraries/base/GHC/Base.hs | @@ -964,10 +964,12 @@ mapFB c f = \x ys -> c (f x) ys | -- (along with build's unfolding) else we'd get an infinite loop | -- in the rules. Hence the activation control below. | -- | --- The "mapFB" rule optimises compositions of map. | --- | -- This same pattern is followed by many other functions: | -- e.g. append, filter, iterate, repeat, etc. | +-- | +-- The "mapFB" rule optimises compositions of map and | +-- the "mapFB/id" rule get rids of 'map id' calls. | +-- (Any similarity to the Functor laws for [] is expected.) | | {-# RULES | "map" [~1] forall f xs. map f xs = build (\c n | -> foldr (mapFB c f) n xs) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C8854d69a18b4459e52880 | 8d466feef08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466925100 | 80066&sdata=cU6XkSWb5Lg1oaEnVPwB2%2BesI9jtneA2051MhD4SnnM%3D&reserved= | 0

2 1

Better perf
by Simon Peyton Jones 09 Mar '17

09 Mar '17

I've just committed this patch sequence fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels idemoptent on bottoming functions 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor 9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile 9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal strings In my final validate run (after updating to HEAD) I saw Unexpected stat failures: perf/compiler/T13035.run T13035 [stat too good] (normal) -6.4% alloc perf/compiler/T12425.run T12425 [stat too good] (optasm) -6.6% alloc perf/compiler/T9675.run T9675 [stat too good] (optasm) -10.4% alloc perf/compiler/T1969.run T1969 [stat too good] (normal) -21% peak megabytes perf/space_leaks/T4029.run T4029 [stat too good] (ghci) -14% peak megabytes This is good. I did not see these in earlier validations (perhaps I did not rebuild the libraries sufficiently), so I have left them. If Harbormaster agrees that perf has improved, could someone re-centre the numbers? Ideally say which patch is responsible. Simon

3 5

RE: [commit: ghc] master: Deserialize IfaceId more lazily (6446254)
by Simon Peyton Jones 08 Mar '17

08 Mar '17

Reid I beg you to add a comment to these carefully-placed used of laziness! The informative commit message does not appear in the code :-). Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 03 March 2017 21:36 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Deserialize IfaceId more lazily | (6446254) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F644625449a9b6fbeb9a81f1a7d0e7d184 | 24fb707%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9b1a8ffea4684b8 | f5e7608d4627d690f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362417 | 38152433434&sdata=H81TTDPPgdp%2BYQzqRFUtiyyfm%2Fn6YRQT%2BoOpJuehsOU%3D | &reserved=0 | | >--------------------------------------------------------------- | | commit 644625449a9b6fbeb9a81f1a7d0e7d18424fb707 | Author: Reid Barton <rwbarton(a)gmail.com> | Date: Fri Mar 3 15:49:38 2017 -0500 | | Deserialize IfaceId more lazily | | This change sped up the total validate --build-only time by 0.8% | on my test system; hopefully a representative result. | | I didn't bother making the other constructors lazy because for | IfaceData and IfaceClass we need to pull on some of the fields | in loadDecl, and all the others seem much more rare than IfaceId. | | Test Plan: validate, perf | | Reviewers: austin, bgamari | | Reviewed By: bgamari | | Subscribers: thomie | | Differential Revision: https://phabricator.haskell.org/D3269 | | | >--------------------------------------------------------------- | | 644625449a9b6fbeb9a81f1a7d0e7d18424fb707 | compiler/iface/IfaceSyn.hs | 8 ++------ | 1 file changed, 2 insertions(+), 6 deletions(-) | | diff --git a/compiler/iface/IfaceSyn.hs b/compiler/iface/IfaceSyn.hs | index d73a738..1c30476 100644 | --- a/compiler/iface/IfaceSyn.hs | +++ b/compiler/iface/IfaceSyn.hs | @@ -1565,9 +1565,7 @@ instance Binary IfaceDecl where | put_ bh (IfaceId name ty details idinfo) = do | putByte bh 0 | putIfaceTopBndr bh name | - put_ bh ty | - put_ bh details | - put_ bh idinfo | + lazyPut bh (ty, details, idinfo) | | put_ bh (IfaceData a1 a2 a3 a4 a5 a6 a7 a8 a9) = do | putByte bh 2 | @@ -1657,9 +1655,7 @@ instance Binary IfaceDecl where | h <- getByte bh | case h of | 0 -> do name <- get bh | - ty <- get bh | - details <- get bh | - idinfo <- get bh | + ~(ty, details, idinfo) <- lazyGet bh | return (IfaceId name ty details idinfo) | 1 -> error "Binary.get(TyClDecl): ForeignType" | 2 -> do a1 <- getIfaceTopBndr bh | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9b1a8ffea4684b8f5e760 | 8d4627d690f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362417381524 | 33434&sdata=L1dvXY%2BW%2Brv4gMqeWm8BGfIPifKK0DBndoJVF%2FCfu0c%3D&reser | ved=0

2 1

RE: [commit: ghc] master: Add rule mapFB c (λx.x) = c (2fa4421)
by Simon Peyton Jones 08 Mar '17

08 Mar '17

Joachim Please, I beg you, add a comment to explain why this rule is useful. I'm sure you had a good reason for adding it, but it's not apparent from the code. Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 06 March 2017 23:52 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Add rule mapFB c (λx.x) = c (2fa4421) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F2fa44217c1d9722227297eefb0d6c6aed | 7e128ca%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cc5db3687da004cd | 11d0f08d464ebc6ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362444 | 11212143808&sdata=KMHS17MUXQUkBOaMbFiRxXiRM8gIvlEMGz%2FDw7F7Njo%3D&res | erved=0 | | >--------------------------------------------------------------- | | commit 2fa44217c1d9722227297eefb0d6c6aed7e128ca | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Mon Mar 6 17:30:52 2017 -0500 | | Add rule mapFB c (λx.x) = c | | Test Plan: exended T2110 with a case for that. | | Reviewers: austin, hvr, dfeuer, bgamari | | Reviewed By: dfeuer | | Subscribers: dfeuer, thomie | | Differential Revision: https://phabricator.haskell.org/D3275 | | | >--------------------------------------------------------------- | | 2fa44217c1d9722227297eefb0d6c6aed7e128ca | libraries/base/GHC/Base.hs | 1 + | testsuite/tests/simplCore/should_run/T2110.hs | 3 +++ | testsuite/tests/simplCore/should_run/T2110.stdout | 1 + | 3 files changed, 5 insertions(+) | | diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs | index 2f155c6..6f9d454 100644 | --- a/libraries/base/GHC/Base.hs | +++ b/libraries/base/GHC/Base.hs | @@ -973,6 +973,7 @@ mapFB c f = \x ys -> c (f x) ys | "map" [~1] forall f xs. map f xs = build (\c n | -> foldr (mapFB c f) n xs) | "mapList" [1] forall f. foldr (mapFB (:) f) [] = map f | "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c | (f.g) | +"mapFB/id" forall c. mapFB c (\x -> x) = c | #-} | | -- See Breitner, Eisenberg, Peyton Jones, and Weirich, "Safe Zero- | cost diff --git a/testsuite/tests/simplCore/should_run/T2110.hs | b/testsuite/tests/simplCore/should_run/T2110.hs | index 610be09..d945fac 100644 | --- a/testsuite/tests/simplCore/should_run/T2110.hs | +++ b/testsuite/tests/simplCore/should_run/T2110.hs | @@ -5,6 +5,8 @@ import Unsafe.Coerce | | newtype Age = Age Int | | +foo :: [Int] -> [Int] | +foo = map id | fooAge :: [Int] -> [Age] | fooAge = map Age | fooCoerce :: [Int] -> [Age] | @@ -19,6 +21,7 @@ same x y = case reallyUnsafePtrEquality# | (unsafeCoerce x) y of | | main = do | let l = [1,2,3] | + same (foo l) l | same (fooAge l) l | same (fooCoerce l) l | same (fooUnsafeCoerce l) l | diff --git a/testsuite/tests/simplCore/should_run/T2110.stdout | b/testsuite/tests/simplCore/should_run/T2110.stdout | index 55f7ebb..4ff957b 100644 | --- a/testsuite/tests/simplCore/should_run/T2110.stdout | +++ b/testsuite/tests/simplCore/should_run/T2110.stdout | @@ -1,3 +1,4 @@ | yes | yes | yes | +yes | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cc5db3687da004cd11d0f0 | 8d464ebc6ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362444112121 | 43808&sdata=y%2BRYDSeV9k2Uj%2BlPtE%2BeIeG05mQvE97QV0B0wgl7cx4%3D&reser | ved=0

2 1

Better conditionals
by Simon Peyton Jones 08 Mar '17

08 Mar '17

Reid As promised: could you look at Trac #13397, re tagToEnum#. In particular, why is n-body running slower?? The change is basically a good one: removes a nasty special case in the code generator and de-clutters the code generally. So I'm keen to keep it. Not important for 8.2 though. Thanks Simon

1 0