January 2017 - ghc-devs

RE: Floating lazy primops
by David Feuer 24 Jan '17

24 Jan '17

I've opened #13182 to explore one possible approach to dataToTag# that strikes me as likely to be simpler and to have fewer potential gotchas. But there could be critical points I'm missing about why we do it as we do now. -------- Original message --------From: Simon Peyton Jones <simonpj(a)microsoft.com> Date: 1/23/17 4:47 PM (GMT-05:00) To: David Feuer <david(a)well-typed.com> Cc: ghc-devs(a)haskell.org Subject: RE: Floating lazy primops We should have this conversation on a ticket, perhaps #13027. | good at the time). Are there actually any primops with lifted arguments | where we *want* speculation? Perhaps the most important primop to | consider is seq#, which is I don't understand this question. comment:23 of #13027 specifically says to skip the ok-for-spec test for lifted args. So you as "are the any" whereas comment:23 says "all". | 2. If dataToTag# is marked can_fail (an aspect of https:// | phabricator.haskell.org/rGHC5a9a1738023a) is it still possible for it to | end up being applied to an unevaluated argument? If not, perhaps the | CorePrep specials can be removed altogether. That may be true, but it's not easy to GUARANTEE in the way that Lint guarantees types. So I'm happier leaving in the CorePrep stuff.. but please do add a comment there that points to the Note in primops.txt.pp and says that it seems unlikely this will ever occur. | One more question: do you think it's *better* to let dataToTag# float and | then fix it up later, or better to mark it can_fail? Unlike | reallyUnsafePtrEquality#, dataToTag# is used all over the place, so it is | important that it interacts as well as possible with the optimizer, | whatever that entails. I think better to do as now. That way the simplifier has the opportunity to common-up multiple evals into one. If we add them later that's harder. By all means add Notes to explain this. Thanks! Simon | -----Original Message----- | From: David Feuer [mailto:david@well-typed.com] | Sent: 18 January 2017 19:45 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Cc: ghc-devs(a)haskell.org | Subject: Floating lazy primops | | I opened up https://phabricator.haskell.org/D2987 to mark | reallyUnsafePtrEquality# can_fail, but in the process I realized a couple | things. | | 1. Part of https://phabricator.haskell.org/rGHC5a9a1738023a may actually | not have been such a hot idea after all (although it certainly sounded | good at the time). Are there actually any primops with lifted arguments | where we *want* speculation? Perhaps the most important primop to | consider is seq#, which is | (mysteriously?) marked neither can_fail nor has_side_effects, but another | to look at is unpackClosure#, which seems likely to give different | results before and after forcing. Most other primops with lifted | arguments are marked has_side_effects, and therefore won't be floated out | anyway. | | 2. If dataToTag# is marked can_fail (an aspect of https:// | phabricator.haskell.org/rGHC5a9a1738023a) is it still possible for it to | end up being applied to an unevaluated argument? If not, perhaps the | CorePrep specials can be removed altogether. | | David Feuer

1 0

StablePtr / StableName ?
by Johannes Waldmann 24 Jan '17

24 Jan '17

Dear ghc devs, would the StablePtr performance issue (slow hash table) https://ghc.haskell.org/trac/ghc/ticket/13165 also affect StableNames? Cf. https://github.com/ekmett/ersatz/issues/30 Could making 10^5 stable names, and accessing each just once, take noticeable time? Where would this show up in a profile? I guess there's no easy way to change the ersatz library (StableName this is the fundamental mechanism for detecting sharing) but if these issues are related, then ersatz provides a performance test case. Thanks, Johannes.

3 3

Floating lazy primops
by David Feuer 23 Jan '17

23 Jan '17

I opened up https://phabricator.haskell.org/D2987 to mark reallyUnsafePtrEquality# can_fail, but in the process I realized a couple things. 1. Part of https://phabricator.haskell.org/rGHC5a9a1738023a may actually not have been such a hot idea after all (although it certainly sounded good at the time). Are there actually any primops with lifted arguments where we *want* speculation? Perhaps the most important primop to consider is seq#, which is (mysteriously?) marked neither can_fail nor has_side_effects, but another to look at is unpackClosure#, which seems likely to give different results before and after forcing. Most other primops with lifted arguments are marked has_side_effects, and therefore won't be floated out anyway. 2. If dataToTag# is marked can_fail (an aspect of https:// phabricator.haskell.org/rGHC5a9a1738023a) is it still possible for it to end up being applied to an unevaluated argument? If not, perhaps the CorePrep specials can be removed altogether. David Feuer

2 2

RE: [Diffusion] [Build Failed] rGHCb78fa759bfb4: Simplify and improve CSE
by Simon Peyton Jones 20 Jan '17

20 Jan '17

I'm sorry about all these Phab failures. I'm struggling with arc, and so committing directly. It all validates fine on my machine. They seem to be all about T1969. It validates fine on my machine. But only just! On my machine I get peak_megabytes = 64; but on Harbormaster it seems to be 65 or 66. But I think 64 is *just* within the 20% margin from 55, and 65 is just outside. The increase might well be peak-memory sampling noise. Anyway it looks as if the 20% increase all occurred some time ago. Maybe we should look at when and why? But meanwhile, Ben/Reid/David, if you agree that the increase is some time ago, would you like to re-centre the number and (maybe) open a ticket to find where the increase actually happened. I have to go home now... apologies. Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 20 January 2017 17:13 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHCb78fa759bfb4: Simplify and improve CSE Harbormaster failed to build B13285: rGHCb78fa759bfb4: Simplify and improve CSE! BRANCHES master USERS simonpj (Author) O7 (Auditor) O12 (Auditor) COMMIT https://phabricator.haskell.org/rGHCb78fa759bfb4 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 1

T13156
by Ben Gamari 20 Jan '17

20 Jan '17

Hi Simon, I'm seeing some rather peculiar validation issues with your most recent patch. Namely, =====> T13156(normal) 1 of 1 [0, 0, 0] cd "./simplCore/should_compile/T13156.run" && $MAKE -s --no-print-directory T13156 Actual stdout output differs from expected: diff -uw "./simplCore/should_compile/T13156.run/T13156.stdout.normalised" "./simplCore/should_compile/T13156.run/T13156.run.stdout.normalised" --- ./simplCore/should_compile/T13156.run/T13156.stdout.normalised 2017-01-20 13:00:46.620654541 -0500 +++ ./simplCore/should_compile/T13156.run/T13156.run.stdout.normalised 2017-01-20 13:00:46.620654541 -0500 @@ -1,5 +1,2 @@ case GHC.List.reverse @ a x of sat { __DEFAULT -> - case \ (@ a) -> - case g x of { - case r @ GHC.Types.Any of { __DEFAULT -> - case r @ GHC.Types.Any of { __DEFAULT -> GHC.Types.True } + case case g x of { Oddly enough Harbormaster isn't reproducing this, but it seems to be quite reproducible locally. Do you have any idea what might be going on here? Cheers, - Ben

1 1

Arc doesn't work
by Simon Peyton Jones 20 Jan '17

20 Jan '17

I can't use arc. At the end of 'arc diff' it says Exception Some linters failed: - CommandException: Command failed with error #1! COMMAND python3 .arc-linters/check-cpp.py 'compiler/basicTypes/Id.hs' STDOUT (empty) STDERR File ".arc-linters/check-cpp.py", line 28 r = re.compile(rb'ASSERT\s+\(') ^ SyntaxError: invalid syntax (Run with `--trace` for a full exception trace.) simonpj@cam-05-unx:~/code/HEAD-3$ python3 --version python3 --version Python 3.2.3 Alas. Simon

2 3

RE: Arc doesn't work
by Simon Peyton Jones 20 Jan '17

20 Jan '17

Have you tried to 'arc upgrade'? Yes, I did that. It did upgrade successfully, but had no effect on this. S From: Simon Peyton Jones Sent: 20 January 2017 17:11 To: 'Alan & Kim Zimmerman' <alan.zimm(a)gmail.com> Subject: RE: Arc doesn't work Have you tried to 'arc upgrade'? Yes, I did that. It did upgrade successfully, but had no effect on this. S From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com] Sent: 20 January 2017 16:18 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: Arc doesn't work Have you tried to 'arc upgrade'? On 20 January 2017 at 17:50, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: I can’t use arc. At the end of ‘arc diff’ it says Exception Some linters failed: - CommandException: Command failed with error #1! COMMAND python3 .arc-linters/check-cpp.py 'compiler/basicTypes/Id.hs' STDOUT (empty) STDERR File ".arc-linters/check-cpp.py", line 28 r = re.compile(rb'ASSERT\s+\(') ^ SyntaxError: invalid syntax (Run with `--trace` for a full exception trace.) simonpj@cam-05-unx:~/code/HEAD-3$ python3 --version python3 --version Python 3.2.3 Alas. Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 0

Magical function to support reflection
by David Feuer 20 Jan '17

20 Jan '17

The following proposal (with fancier formatting and some improved wording) can be viewed at https://ghc.haskell.org/trac/ghc/wiki/MagicalReflectionSupport Using the Data.Reflection has some runtime costs. Notably, there can be no inlining or unboxing of reified values. I think it would be nice to add a GHC special to support it. I'll get right to the point of what I want, and then give a bit of background about why. === What I want I propose the following absurdly over-general lie: reify# :: (forall s . c s a => t s r) -> a -> r `c` is assumed to be a single-method class with no superclasses whose dictionary representation is exactly the same as the representation of `a`, and `t s r` is assumed to be a newtype wrapper around `r`. In desugaring, reify# f would be compiled to f@S, where S is a fresh type. I believe it's necessary to use a fresh type to prevent specialization from mixing up different reified values. === Background Let me set up a few pieces. These pieces are slightly modified from what the package actually does to make things cleaner under the hood, but the differences are fairly shallow. newtype Tagged s a = Tagged { unTagged :: a } unproxy :: (Proxy s -> a) -> Tagged s a unproxy f = Tagged (f Proxy) class Reifies s a | s -> a where reflect' :: Tagged s a -- For convenience reflect :: forall s a proxy . Reifies s a => proxy s -> a reflect _ = unTagged (reflect' :: Tagged s a) -- The key function--see below regarding implementation reify' :: (forall s . Reifies s a => Tagged s r) -> a -> r -- For convenience reify :: a -> (forall s . Reifies s a => Proxy s -> r) -> r reify a f = reify' (unproxy f) a The key idea of reify' is that something of type forall s . Reifies s a => Tagged s r is represented in memory exactly the same as a function of type a -> r So we can currently use unsafeCoerce to interpret one as the other. Following the general approach of the library, we can do this as such: newtype Magic a r = Magic (forall s . Reifies s a => Tagged s r) reify' :: (forall s . Reifies s a => Tagged s r) -> a -> r reify' f = unsafeCoerce (Magic f) This certainly works. The trouble is that any knowledge about what is reflected is totally lost. For instance, if I write reify 12 $ \p -> reflect p + 3 then GHC will not see, at compile time, that the result is 15. If I write reify (+1) $ \p -> reflect p x then GHC will never inline the application of (+1). Etc. I'd like to replace reify' with reify# to avoid this problem. Thanks, David Feuer

6 16

Type family bug?
by Simon Peyton Jones 19 Jan '17

19 Jan '17

Richard This works type family F (a :: k) type instance F Maybe = Char But this does not. Surely it should? type family F (a :: k) where -- = r | r -> a where F Maybe = Char The latter is rejected with Foo.hs:6:5: error: * Expecting one more argument to `Maybe' Expected kind `k', but `Maybe' has kind `* -> *' * In the first argument of `F', namely `Maybe' In the type family declaration for `F' If you agree I'll open a ticket. Simon

2 1

Building RUNPATH into ghc binaries for 3rd-party libraries
by Albert Chin 18 Jan '17

18 Jan '17

Hi. I am building ghc-8.0.2 on RHEL 6 and trying to get the runtime path for 3rd-party libraries outside of the system search path embedded into the ghc binaries. Specifically, this is for libffi and libgmp. I am using the attached patch for this and it seems to work for the most part. It does not work for ghc-iserv through: $ cd /usr/local/ghc80/lib/ghc-8.0.2/bin $ ldd ghc-iserv linux-vdso.so.1 => (0x00007fffba3ff000) librt.so.1 => /lib64/librt.so.1 (0x00000033e0e00000) libutil.so.1 => /lib64/libutil.so.1 (0x00000033f0200000) libdl.so.2 => /lib64/libdl.so.2 (0x00000033e0600000) libgmp.so.10 => not found libm.so.6 => /lib64/libm.so.6 (0x00000033e0200000) libffi.so.6 => not found libpthread.so.0 => /lib64/libpthread.so.0 (0x00000033e0a00000) libc.so.6 => /lib64/libc.so.6 (0x00000033dfe00000) /lib64/ld-linux-x86-64.so.2 (0x00000033dfa00000) I presume I need to add something like the following to iserv/ghc.mk somewhere? -optl-Wl,-rpath,$(FFILibDir) \ -optl-Wl,-rpath,$(GMP_LIB_DIRS) \ -- albert chin (china(a)thewrittenword.com)

1 0