- ghc-devs - Haskell.org

Simplifier vs. rules problem
by michael.sperber＠active-group.de 11 Sep '20

11 Sep '20

I've been trying to make Conal's ConCat plugin work for polymorphic code, and am running into some problems with the ghc doing that, and I'd very much appreciate help with that. Background: I'm trying to get -dcore-lint to flag when my actual problem happens (has to do with dictionary construction, but it fails earlier with another problem, which I think comes from the simplifier. tl;dr: This transformation seems to me problematic: https://ghc-compiler-notes.readthedocs.io/en/latest/notes/compiler/simplCor… The docs for the transformation say that it makes this replacement: case a +# b of r -> …r… into let r = a +# b in …r… But this creates a let binding with an unlifted binder, which the linter does not like: <no location info>: warning: [RHS of ... :: Int#] The type of this binder is unlifted: ... Binder's type: Int# Arguably, this rule might expect the let to be inlined, but we're seeing that the let stands, and the linter complains. My immediate concern is getting around this problem somehow so I can run the linter on later output of the simplifier. Is there any way to do this? I.e. don't stop when the linter complains, somehow massage the rules to work better - see below. Any help would be much appreciated! (I'm using ghc 8.8.3.) More details: The ConCat code has this rule: "rebox2" [~0] (+#) = \ u# v# -> unboxI (addC (boxI u#, boxI v#)) It fires like this: Rule fired Rule: rebox_2 Module: (ConCat.Rebox) Before: GHC.Prim.+# ValArg 10# ValArg 1# After: (\ (u#_aM4G :: GHC.Prim.Int#) (v#_aM4H :: GHC.Prim.Int#) -> ConCat.Rebox.unboxI (ConCat.AltCat.addC @ (->) @ GHC.Types.Int (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt) (ConCat.Rebox.boxI u#_aM4G, ConCat.Rebox.boxI v#_aM4H))) 10# 1# Cont: Stop[BoringCtxt] GHC.Prim.Int# ... and comes out of the simplifier like this: let { n1_sM4V :: GHC.Prim.Int# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 0}] n1_sM4V = case ConCat.AltCat.addC @ (->) @ GHC.Types.Int (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt) (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#) of { GHC.Types.I# i#_aM4S -> i#_aM4S } } in GHC.Types.I# (case ConCat.AltCat.addC @ (->) @ GHC.Types.Int (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt) (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#) of { GHC.Types.I# i#_aM4S -> i#_aM4S }) } in ... Ironically, you can see that the simplifier already *has* inlined, just not elided the (now dead) let binding yet, before the linter gets to it. I've also attached a shorter source file with the relevant rules that triggers the linter, albeit with a different message. Richard Eisenberg, Gabor Greif, and Conal helped me get to this point. Many thanks to them! -- Regards, Mike {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -frewrite-rules #-} {-# OPTIONS_GHC -ddump-rule-rewrites #-} {-# OPTIONS_GHC -ddump-rules #-} {-# OPTIONS_GHC -dcore-lint #-} {-# OPTIONS_GHC -ddump-simpl #-} module ConCatRules where import GHC.Prim import GHC.Int boxI :: Int# -> Int boxI = I# {-# INLINE [0] boxI #-} unboxI :: Int -> Int# unboxI (I# i#) = i# -- {-# INLINE [0] unboxI #-} plus :: Int -> Int -> Int plus x y = undefined {-# NOINLINE plus #-} {-# RULES "reboxa" forall u# v# . (+#) u# v# = unboxI (plus (boxI u#) (boxI v#)) "reboxb" forall u# . (+#) u# = \v# -> unboxI (plus (boxI u#) (boxI v#)) "reboxc" (+#) = \ u# v# -> unboxI (plus (boxI u#) (boxI v#)) #-} foo = I# (10# +# 1#)

2 1

!RE: Implicit reboxing of unboxed tuple in let-patterns
by Simon Peyton Jones 10 Sep '20

10 Sep '20

I’m a bit late to this debate, but here are a few thoughts. 1. “Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the binding is strict.” Not only is this rule simple and consistent, it is also necessary: we cannot bind a variable of unlifted type to a thunk. So any new rule must include this, and maybe add something extra, complicating the language. 1. All lazy pattern bindings go via an intermediate tuple. If you write (Just x, [y]) = e then you get t = case e of (Just x, [y]) -> (x,y) x = fst t y = snd t The pattern can be complex and we don’t want to unpack it many times. Moreover, the semantics says that it must be fully matched, so even if you just want ‘x’, you must check that the second component of the pair is indeed a singleton list. So the “going via a tuple” part is nothing special about unboxed tuples – it simply holds for all lazy pattern bindings. 1. I don’t understand the details of Iavor’s proposal to add that “unlifted patterns are strict”, in addition to (1). Do you mean “any sub-pattern of the LHS has an unlifted type”? So Just (# a,b #) = e would be strict. And even MkT _ = e would be strict if data T = MkT (# Int,Int #) 1. Anything we do *must* scale to when we have user-defined unlifted data types (a current GHC Proposal) TL;DR. At the moment a change does not look attractive to me. I could live with a warning for *outermost* unboxed tuples (or in general a constructor of an unlifted data type), suggesting to add a “!” or a “~” to make the intent clear. Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Richard Eisenberg Sent: 02 September 2020 14:47 To: Spiwack, Arnaud <arnaud.spiwack(a)tweag.io> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: Re: Implicit reboxing of unboxed tuple in let-patterns On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack(a)tweag.io<mailto:arnaud.spiwack@tweag.io>> wrote: Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know what the semantics of these ought to be. It does look like an interesting can of worms. How do they currently desugar? Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the pattern is an unlifter-var pattern and is strict. The pattern must be banged, unless the bound variable is not nested. This rule is consistent across all features. This thread is suggesting to add a special case -- one that seems to match intuition, but it's still a special case. And my question is: should the special case be for unboxed tuples? or should the special case be for any pattern whose overall type is unlifted? Richard

5 8

non-threaded rts and CollectGarbage
by Moritz Angermann 09 Sep '20

09 Sep '20

Hi there! in the non-threaded rts we use itimer to do light weight scheduling of threads via SIGALRM signals. I'm seeing quite a bit of heap corruption on aarch64, and it appears that I also see a lot of signal handling in the GC, for example during evacuate. Is there a fundamental reason why we can't just disable the timer during GC? Cheers, Moritz

1 0

Implicit reboxing of unboxed tuple in let-patterns
by Spiwack, Arnaud 07 Sep '20

07 Sep '20

Dear all, I discovered the hard way, yesterday, that lazy let pattern matching is allowed on unboxed tuples. And that it implicitly reboxes the pattern. Here is how the manual describes it, from the relevant section <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts…> : You can have an unboxed tuple in a pattern binding, thus f x = let (# p,q #) = h x in ..body.. If the types of p and q are not unboxed, the resulting binding is lazy like any other Haskell pattern binding. The above example desugars like this: f x = let t = case h x of { (# p,q #) -> (p,q) } p = fst t q = snd t in ..body.. Indeed, the bindings can even be recursive. Notice how h x is lazily bound, hence won’t necessarily be run when body is forced. as opposed to if I had written, for instance, let u = hxin ..body.. My question is: are we happy with this? I did find this extremely surprising. If I’m using unboxed tuples, it’s because I want to guarantee to myself a strict, unboxed behaviour. But a very subtle syntactic detail seems to break this expectation for me. My expectation would be that I would need to explicitly rebox things before they get lazy again. I find that this behaviour invites trouble. But you may disagree. Let me know!

8 20

COMPLETE pragmas
by Richard Eisenberg 03 Sep '20

03 Sep '20

Hi Sebastian, I enjoyed your presentation last week at ICFP! This thread (https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-…) played out before you became so interested in pattern-match coverage. I'd be curious for your thoughts there -- do you agree with the conclusions in the thread? My motivation for asking is https://github.com/conal/linalg/pull/54 (you don't need to read the whole thing), which can be boiled down to a request for a COMPLETE pragma that works at a polymorphic result type. (Or a COMPLETE pragma written in a module that is not the defining module for a pattern synonym.) https://gitlab.haskell.org/ghc/ghc/-/issues/14422 describes a similar, but even more challenging scenario. Do you see any ways forward here? Thanks! Richard

5 8

GHC Logo
by Ben Gamari 02 Sep '20

02 Sep '20

Hi everyone, Recently a sponsor asked for a logo for our project. As far as I know, GHC doesn't really have a consistent logo; the closest that we have had is the stylized "GHC" on the top of ghc.haskell.org. To accomodate the request, I took a few minutes and reworked the typography of the Thompson-Wheeler Haskell logo for use by GHC. I couldn't positively identify the typeface used for the "Haskell" text, but I believe that the extra-bold Cantarell face that I chose in the GHC variant has a similar feel to the Haskell logo and is free to use. I've posted the logo on the Wiki for future reference [1]. Feedback is very much welcome. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo

13 22

Creative ideas on how to debug heap corruption
by Moritz Angermann 02 Sep '20

02 Sep '20

Hi there! as some of you may know, I've been working on an aarch64 native code generator. Now I've hit a situation where my stage2 compiler somehow corrupts my heap. Initially I thought this would likely be missing memory barriers, however they are emitted. This doesn't mean it can't be, but at least it's not as simple as "they are just missing". The crashes I see are non deterministic, in fact I sometimes even manage to compile a Hello World module, without crashes. Other times it crashes with unknown closure errors or it just crashes. But it always crashes during GC. Changing the nursery size make it crasha bit more frequent, but nothing obvious sticks out yet. If anyone has some create ideas, I'd love to hear them. I've been wondering if just logging allocations (offset, range, type) would help figuring out what we expected to be there; and then maybe try to break on the allocation, (and subsequent writes). I'm sure some have been down this road before. Cheers, Moritz

5 7

HsPragTick
by Alan & Kim Zimmerman 02 Sep '20

02 Sep '20

I am working through the API Annotations, and have come across HsPragTick. In source it appears as c = {-# GENERATED "foobar" 1 : 2 - 3 : 4 #-} 0.00 But it does not seem to be used anywhere. It is passed through for renaming and type checking, and Coverage.hs uses it as addTickHsExpr (HsPragE _ HsPragTick{} (L pos e0)) = do e2 <- allocTickBox (ExpBox False) False False (locA pos) $ addTickHsExpr e0 return $ unLoc e2 So if it is used at all, the contents are ignored. Can it be removed? Alan

2 1

Re: HsPragTick
by Ryan Scott 31 Aug '20

31 Aug '20

I think that HsPragTick is unused as of [1]. In fact, I was under the impression that [1] removed HsPragTick entirely (as the commit message) would suggest, but upon further inspection, that doesn't appear to be the case. Vlad, do you recall why HsPragTick was kept around? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2154

3 2

Parsing funny arrows
by Csongor Kiss 29 Aug '20

29 Aug '20

Hello devs, I am trying to modify GHC's parser to allow the following syntax in types: a -> @m b but my naive attempt was unsuccessful: type :: { LHsType GhcPs } : btype { $1 } | btype '->' PREFIX_AT btype ctype ... For example when I try to parse the following code (and turn on the lexer debug log): test :: a -> @m b test = undefined I get the following token: ITvarid "test" token: ITdcolon NormalSyntax token: ITvarid "a" token: ITrarrow NormalSyntax token: ITtypeApp token: ITvarid "m" token: ITvarid "b" token: ITsemi Parse.hs:2:1: error: parse error (possibly incorrect indentation or mismatched brackets) | 2 | test = undefined I don't have much experience with hacking on the parser so I'm likely missing something obvious. Could someone please point at what I might be doing wrong? Thanks in advance. Cheers, Csongor

4 8