- ghc-devs - Haskell.org

New primitive types?
by Michal Terepeta 26 Sep '17

26 Sep '17

Hi all, I'm working on making it possible to pack constructor fields [1], example: ``` data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32 ``` should only require 4 bytes for unpacked `Float` and 4 bytes for unpacked `Int32`, which on 64-bit arch would take just 1 word (instead of 2 it currently does). The diff to support packing of fields is in review [2], but to really take advantage of it I think we need to introduce new primitive types: - Int{8,16,32}# - Word{8,16,32}# along with some corresponding primops and with some other follow-up changes like extending `PrimRep`. Then we could use them in definitions of `Int{8,16,32}` and `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`). Does that sound ok with everyone? (just making sure that this makes sense before I invest more time into this :) Thanks, Michal [1] https://ghc.haskell.org/trac/ghc/ticket/13825 [2] https://phabricator.haskell.org/D3809

4 9

Re: Why isn't this Typeable?
by Richard Eisenberg 25 Sep '17

25 Sep '17

I think we're a long way off from supporting Typeable for higher-kinded types, so I wouldn't worry about that dark, spider-ridden corner. Richard > On Sep 25, 2017, at 3:00 PM, David Feuer <david(a)well-typed.com> wrote: > > No. What led me down this path is that I was thinking about whether we could simplify the representation and reduce the TCB. The as-yet-incomplete ideas I had (largely based on the concept of using a constructor name as a singletons-style defunctionalization symbol) seem difficult to adapt to the generalization I describe, so I wanted to check first how much that matters. > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Richard Eisenberg <rae(a)cs.brynmawr.edu> > Date: 9/25/17 2:42 PM (GMT-05:00) > To: David Feuer <david(a)well-typed.com> > Cc: Ben Gamari <ben(a)smart-cactus.org>, ghc-devs(a)haskell.org > Subject: Re: Why isn't this Typeable? > > I suppose this is conceivable, but it would complicate the representation and solver for TypeReps considerably. Do you have a real use case? > > Richard > > > On Sep 25, 2017, at 2:28 PM, David Feuer <david(a)well-typed.com> wrote: > > > > My example wasn't quite the one I intended (although I think it should > > work as well, and it's simpler). Here's the sort of example I really intended: > > > > data Bar :: forall (j :: forall k. k -> Maybe k) (a :: Type). Proxy (j a) -> Type > > > > I would expect > > > > Bar :: Proxy ('Just Int) -> Type > > > > or, to abuse notation a bit, > > > > Bar @'Just @Int > > > > to be Typeable. What I'm really suggesting is that we should distinguish between things that are typeable and > > things that can be decomposed into typeable components. We already make a limited distinction > > here. For example, we have > > > > 'Just :: forall a. a -> Maybe a > > > > 'Just itself cannot be Typeable, but once it's applied to a kind variable, it is Typeable. > > 'Just @Int is Typeable even though that (kind) application cannot be broken with App. Similarly, I'd expect > > Foo 'Just to be Typeable even though that (type) application cannot be broken with App (or Fun). > > > > Putting things in terms of fingerprints, we can offer type-indexed fingerprints > > > > newtype Finger a = Finger Fingerprint > > > > for anything we can fingerprint. Is there any difficulty fingerprinting types like Foo 'Just and > > Bar @'Just @Int? Fingerprints are useful for lots of applications where decomposition isn't > > necessary. > > > > On Sunday, September 24, 2017 1:16:37 PM EDT Richard Eisenberg wrote: > >> The problem is that to get Typeable (Foo 'Just), we need Typeable 'Just. However, the kind parameter for Typeable 'Just would be (forall a. a -> Maybe a), making the full constraint Typable (forall a. a -> Maybe a) 'Just. And saying that would be impredicative. In other contexts, 'Just *can* be Typeable, but it's 'Just invisibly instantiated at some monotype for `a`. > >> > >> So I think that this boils down to impredicativity and that the implementation is doing the right thing here. > >> > >> Richard > >> > >>> On Sep 24, 2017, at 5:45 AM, David Feuer <david(a)well-typed.com> wrote: > >>> > >>> data Foo :: (forall a. a -> Maybe a) -> Type > >>> > >>> Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? > >>> > >>> David Feuer > >>> Well-Typed, LLP > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs(a)haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > > >

1 0

Re: Why isn't this Typeable?
by David Feuer 25 Sep '17

25 Sep '17

No. What led me down this path is that I was thinking about whether we could simplify the representation and reduce the TCB. The as-yet-incomplete ideas I had (largely based on the concept of using a constructor name as a singletons-style defunctionalization symbol) seem difficult to adapt to the generalization I describe, so I wanted to check first how much that matters. David FeuerWell-Typed, LLP -------- Original message --------From: Richard Eisenberg <rae(a)cs.brynmawr.edu> Date: 9/25/17 2:42 PM (GMT-05:00) To: David Feuer <david(a)well-typed.com> Cc: Ben Gamari <ben(a)smart-cactus.org>, ghc-devs(a)haskell.org Subject: Re: Why isn't this Typeable? I suppose this is conceivable, but it would complicate the representation and solver for TypeReps considerably. Do you have a real use case? Richard > On Sep 25, 2017, at 2:28 PM, David Feuer <david(a)well-typed.com> wrote: > > My example wasn't quite the one I intended (although I think it should > work as well, and it's simpler). Here's the sort of example I really intended: > > data Bar :: forall (j :: forall k. k -> Maybe k) (a :: Type). Proxy (j a) -> Type > > I would expect > > Bar :: Proxy ('Just Int) -> Type > > or, to abuse notation a bit, > > Bar @'Just @Int > > to be Typeable. What I'm really suggesting is that we should distinguish between things that are typeable and > things that can be decomposed into typeable components. We already make a limited distinction > here. For example, we have > > 'Just :: forall a. a -> Maybe a > > 'Just itself cannot be Typeable, but once it's applied to a kind variable, it is Typeable. > 'Just @Int is Typeable even though that (kind) application cannot be broken with App. Similarly, I'd expect > Foo 'Just to be Typeable even though that (type) application cannot be broken with App (or Fun). > > Putting things in terms of fingerprints, we can offer type-indexed fingerprints > > newtype Finger a = Finger Fingerprint > > for anything we can fingerprint. Is there any difficulty fingerprinting types like Foo 'Just and > Bar @'Just @Int? Fingerprints are useful for lots of applications where decomposition isn't > necessary. > > On Sunday, September 24, 2017 1:16:37 PM EDT Richard Eisenberg wrote: >> The problem is that to get Typeable (Foo 'Just), we need Typeable 'Just. However, the kind parameter for Typeable 'Just would be (forall a. a -> Maybe a), making the full constraint Typable (forall a. a -> Maybe a) 'Just. And saying that would be impredicative. In other contexts, 'Just *can* be Typeable, but it's 'Just invisibly instantiated at some monotype for `a`. >> >> So I think that this boils down to impredicativity and that the implementation is doing the right thing here. >> >> Richard >> >>> On Sep 24, 2017, at 5:45 AM, David Feuer <david(a)well-typed.com> wrote: >>> >>> data Foo :: (forall a. a -> Maybe a) -> Type >>> >>> Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? >>> >>> David Feuer >>> Well-Typed, LLP >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >

1 0

Why isn't this Typeable?
by David Feuer 25 Sep '17

25 Sep '17

data Foo :: (forall a. a -> Maybe a) -> Type Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? David FeuerWell-Typed, LLP

2 3

Re: RTS changes affect runtime when they shouldn’t
by David Feuer 24 Sep '17

24 Sep '17

I think changes to the RTS, code generator, and general heap layout are exactly where we *do* want to worry about these very low-level details. Changes in type checking, desugaring, core-to-core, etc., probably are not, because it's just too hard to tease out the relationship between what they do and what instructions are emitted in the end. David FeuerWell-Typed, LLP -------- Original message --------From: Sven Panne <svenpanne(a)gmail.com> Date: 9/24/17 2:00 PM (GMT-05:00) To: Joachim Breitner <mail(a)joachim-breitner.de> Cc: ghc-devs(a)haskell.org Subject: Re: RTS changes affect runtime when they shouldn’t 2017-09-23 21:06 GMT+02:00 Joachim Breitner <mail(a)joachim-breitner.de>: > what I want to do is to reliably catch regressions. The main question is: Which kind of regressions do you want to catch? Do you care about runtime as experienced by the user? Measure the runtime. Do you care abou code size? Measure the code size. etc. etc. Measuring things like the number of fetched instructions as an indicator for the experienced runtime is basically a useless exercise, unless you do this on ancient RISC processors, where each instruction takes a fixed number of cycles. > What are the odds that a change to the Haskell compiler (in particular to > Core2Core > transformations) will cause a significant increase in runtime without a > significant increase in instruction count? > (Honest question, not rhetoric). > The odds are actually quite high, especially when you define "significant" as "changing a few percent" (which we do!). Just a few examples from current CPUs: * If branch prediction has not enough information to do this better, it assumes that backward branches are taken (think: loops) and forward branches are not taken (so you should put "exceptional" code out of the common, straight-line code). If by some innocent looking change the code layout changes, you can easily get a very measurable difference in runtime even if the number of executed instructions stays exactly the same. * Even if the number of instructions changes only a tiny bit, it could be the case that it is just enough to make caching much worse and/or make the loop stream detector fail to detect a loop. There are lots of other scenarios, so in a nutshell: Measure what you really care about, not something you think might be related to that. As already mentioned in another reply, "perf" can give you very detailed hints about how good your program uses the pipeline, caches, branch prediction etc. Perhaps the performance dashboard should really collect these, too, this would remove a lot of guesswork.

1 0

Re: Why isn't this Typeable?
by David Feuer 24 Sep '17

24 Sep '17

I don't see why Typeable (Foo 'Just) requires that. I'd expect to get back a TrTyCon, not a TrApp. Some modifications to the structure of TrTyCon might be required. David FeuerWell-Typed, LLP -------- Original message --------From: Ryan Scott <ryan.gl.scott(a)gmail.com> Date: 9/24/17 10:08 AM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: Re: Why isn't this Typeable? Trying to conclude Typeable Foo (or, if expanded with -fprint-explicit-kinds, Typeable ((forall a. a -> Maybe a) -> Type) Foo) is beyond GHC's capabilities at the moment, as that would require impredicative polymorphism. This problem has arose in other contexts too—see Trac #13895 [1] for one example. I don't think you can conclude Typeable (Foo 'Just) either, since that requires concluding both Typeable Foo and Typeable 'Just, so you ultimately run into the same problem. While there an in-the-works plan to allow a limited form of impredicativity through explicit use of visible type application [2], my fear is that that wouldn't be enough to address the problem you've encountered, since there's no way to visibly apply @((forall a. a -> Maybe a) -> Type) to Typeable at the moment. To accomplish this, you would need visible kind application [3]. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13895 [2] https://ghc.haskell.org/trac/ghc/ticket/11319#comment:11 [3] https://ghc.haskell.org/trac/ghc/ticket/12045 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Re: Why isn't this Typeable?
by Ryan Scott 24 Sep '17

24 Sep '17

Trying to conclude Typeable Foo (or, if expanded with -fprint-explicit-kinds, Typeable ((forall a. a -> Maybe a) -> Type) Foo) is beyond GHC's capabilities at the moment, as that would require impredicative polymorphism. This problem has arose in other contexts too—see Trac #13895 [1] for one example. I don't think you can conclude Typeable (Foo 'Just) either, since that requires concluding both Typeable Foo and Typeable 'Just, so you ultimately run into the same problem. While there an in-the-works plan to allow a limited form of impredicativity through explicit use of visible type application [2], my fear is that that wouldn't be enough to address the problem you've encountered, since there's no way to visibly apply @((forall a. a -> Maybe a) -> Type) to Typeable at the moment. To accomplish this, you would need visible kind application [3]. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13895 [2] https://ghc.haskell.org/trac/ghc/ticket/11319#comment:11 [3] https://ghc.haskell.org/trac/ghc/ticket/12045

1 0

Ignoring ANN Module "HLint: ..."
by Moritz Angermann 24 Sep '17

24 Sep '17

Hi *, can we detect annotations like `{-# ANN module "HLint: ignore Reduce duplication" #-}` easily? Right now this will result (without -fexternal-interpreter or a stage2 compiler) in Ignoring ANN annotation, because this is a stage-1 compiler without -fexternal-interpreter or doesn't support GHCi However, I do not see why this should require the external interpreter at all. This looks to me more like an informational comment? Cheers, Moritz

2 3

The Curious Case of T6084 -or- Register Confusion with LLVM
by Moritz Angermann 21 Sep '17

21 Sep '17

Hi *, TLDR: The LLVM backend might confuse floating registers in GHC. # Demo (Ticket #14251) Let Demo.hs be the following short program (a minor modification from T6084): ``` {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import GHC.Exts {-# NOINLINE f #-} f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String f g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!" {-# NOINLINE q #-} q :: Int# -> Float# -> Double# -> Float# -> Double# -> String q i j k l m = "Hello " ++ show (F# l) ++ " " ++ show (D# m) main = putStrLn (f $ q) ``` What happens if we compile them with the NCG and LLVM? $ ghc -fasm -fforce-recomp Demo.hs -O2 -o Demo-ncg && ./Demo-ncg Hello 6.0 6.9 World! $ ghc -fllvm -fforce-recomp Demo.hs -O2 -o Demo-llvm && ./Demo-llvm Hello 4.0 5.0 World! # Discussion What is happening here? The LLVM backend passes the registers in arguments, which are then mapped to registers via the GHC calling convention we added to LLVM. As the LLVM backend takes off from Cmm, we produce function that always hold the always live registers (on x86_64 these are: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim) and appends those registers that are live throughout the function call: in the case of `q` this is one Float and one Double register. Let’s assume these are F3 and D4. Thus the function signature we generate looks like: ghccc void @q(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double) And expect the passed arguments to represent the following registers: base, sp, hp, r1, r2, r3, r4, r5, r6, spLim, f3, d4 as we found that f1 and d1 are not live. Yet, when we call `q` in the form of `g` in the body of `f`. We will pass it 14 arguments instead of 12. To make this “typecheck” in LLVM, we @q' = bitcast @q to (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double, float, double) and call @q’(base, sp, hp, r1, r2, r3, r4, r5, r6, spLim, f1, d2, f3, d4). at this point, we now assign f3 <- f1 and d4 <- d2; while silently ignoring the passed arguments f3 and d4. (This is where my llvmng backend fell over, as it does not bitcast function signatures but tries to unify them.) # Solution? Initially, Ben and I though we could simply always pass all registers as arguments in LLVM and call it a day with the downside of create more verbose but correct code. As I found out, that comes with a few complications. For some reason, all active stg registers for my machine give me Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim, F1, D1, F2, D2, F3, D3, XMM1,XMM2,XMM3,XMM4,XMM5,XMM6, YMM1,YMM2,YMM3,YMM4,YMM5,YMM6, ZMM1,ZMM2,ZMM3,ZMM4,ZMM5,ZMM6 I should not have the YMM*, and ZMM* registers as I don’t have any AVX nor AVX512; that looks like only a patch away. However we try to optimize our register, such that we can pass up to six doubles or six floats or any combination of both if needed in registers, without having to allocate them on the stack, by assuming overlapping registers (See Note [Overlapping global registers]). And as such a full function signature in LLVM would as opposed to one that’s based on the “live” registers as we have right now, would consist of 12 float/double registers, and LLVM only maps 6. My current idea is to, pass only the explicit F1,D1,…,F3,D3 and try to disable the register overlapping for LLVM. This would probably force more floating values to be stack allocated rather than passed via registers, but would likely guarantee that the registers match up. The other option I can think of is to define some viertual generic floating registers in the llvm code gen: V1,…,V6 and then perform something like F1 <- V1 as float D1 <- V1 as double in the body of the function, while trying to use the `live` information at the call site to decide which of F1 or D1 to pass as V1. Ideas? Cheers, Moritz

4 6

[PATCH] Enable DTrace support on FreeBSD for dynamically linked RTS
by raichoo 19 Sep '17

19 Sep '17

Hi, I've played around a little bit and came up with a little proof-of-concept patch to enable DTrace support in FreeBSD. I've only managed to get it to work for the dynamically linked RTS. It would be great if someone could take a look at this so this can get possibly merged. :) Kind regards, raichoo

2 3