- ghc-devs - Haskell.org

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

ANN: Overlay Hackage Package Index for GHC HEAD
by Herbert Valerio Riedel 19 Sep '17

19 Sep '17

Hi GHC devs, A long-standing common problem when testing/dogfooding GHC HEAD is that at some point during the development cycle more and more packages from Hackage will run into build failures. Obviously, constantly nagging upstream maintainers to release quickfixes for unreleased GHC HEAD snapshots which will likely break again a few weeks later (as things are generally in flux until freeze comes into effect) does not scale and only introduces a latency/coordination bottleneck, and on top of it ultimately results in spamming the primary Hackage Package index with releases (which has non-negligible negative impact/costs of its own on the Hackage infrastructure, and thus ought to be minimised). OTOH, we need the ability to easily test, debug, profile, and prototype changes to GHC HEAD while things are still in motion, and case in point, if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently run into a dozen or so of packages not building with GHC HEAD. To this end, I've finally found time to work on a side-project (related to matrix.hackage.haskell.org) which implements a scheme tailored to `cabal new-build`, which is inspired by how Eta copes with a very related issue (they rely on it for stable versions of the compiler); i.e., they maintain a set of patches at https://github.com/typelead/eta-hackage/tree/master/patches which fix up existing Hackage packages to work with the Eta compiler. And this gave me the idea to use a similar scheme for GHC HEAD: https://github.com/hvr/head.hackage/tree/master/patches This folder already contains several of patches (which mostly originate from Ryan, Ben and myself) to packages which I needed to patch in order to build popular Hackage packages & tools. The main difference is how those patches are applied; Eta uses a modified `cabal` which they renamed to `etlas` which is checks availability of .patch & .cabal files in the GitHub repo linked above; Whereas for GHC HEAD with `cabal new-build` a different scheme makes more sense: we simply generate an add-on Hackage repo, and use the existing `cabal` facilities (e.g. multi-repo support or the nix-style package store which makes sure that unofficially patched packages don't contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage repo containing fixed up packages. I've tried to describe how to use the HEAD.hackage add-on repo in the README at https://github.com/hvr/head.hackage#how-to-use And finally, here's a practical example of how you can use it to build e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to build your project of choice; please refer to http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html to learn more about how to describe your project via `cabal.project` files): 0.) This assumes you have a recent cabal 2.1 snapshot built from Git 1.) create & `cd` into a new work-folder 2.) invoke `head.hackage.sh update` to update the HEAD.hackage index cache 3.) invoke `head.hackage.sh init` to create an initial `cabal.project` configuration which locally activates the HEAD.hackage overlay repo 4.) If needed, edit the cabal.project file and change where GHC HEAD can be found (the script currently assumes GHC HEAD is installed from my Ubuntu PPA), e.g. with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2 or you can add something like `optional-packages: deps/*/*.cabal` to have cabal pick up package source-trees unpacked in the deps/ folder, or you can inject ghc-options, relax upper bounds via `allow-newer: *:base` etc (please refer to the cabal user guide) 5.) Create a `dummy.cabal` file (in future we will have `cabal new-install` or other facilities, but for now we use this workaround): --8<---------------cut here---------------start------------->8--- name: dummy version: 0 build-type: Simple cabal-version: >=2.0 library default-language: Haskell2010 -- library components you want cabal to solve & build for -- and become accessible via .ghc.environment files and/or -- `cabal new-repl` build-depends: base, lens -- executable components you want cabal to build build-tool-depends: pandoc:pandoc --8<---------------cut here---------------end--------------->8--- 6.) invoke `cabal new-build` 7.) If everything works, you'll find the `pandoc:pandoc` executable somewhere in your ~/.cabal/store/ghc-8.3.*/ folder (you can use http://hackage.haskell.org/package/cabal-plan to conveniently list the location via `cabal-plan list-bins`) 8.) As for libraries, you can either use `cabal new-repl` or you can leverage GHC's package environment files: `cabal new-build` will have generated a file like .ghc.environment.x86_64-linux-8.3.20170913 which brings into scope all transitive dependencies of `build-depends: base, lens` Now all you need to do is simply call ghc-stage2 --make MyTestProg.hs to compile a program against those libs, or start up GHCi via ghc-stage2 --interactive and you'll be thrown into that package environment. I hope you find this useful Cheers, Herbert

6 5

Spurious recompilations when using a compiler plugin
by Conal Elliott 19 Sep '17

19 Sep '17

It appears that use of GHC plugins causes client code to get needlessly recompiled. (See Trac issues 12567 <https://ghc.haskell.org/trac/ghc/ticket/12567> and 7414 <https://ghc.haskell.org/trac/ghc/ticket/7414>.) It’s becoming more of a problem for usability of the plugin <http://conal.net/papers/compiling-to-categories> I’ve been developing, and I’m wondering what can be done. Some questions: - Is there any work in progress on fixing this situation? - Are there serious obstacles to fixing it? - Do plugin writers or users have any workarounds? Other insights appreciated. – Conal

3 3

ANN: preview of alternative llvm code gen
by Moritz Angermann 19 Sep '17

19 Sep '17

Hi, as presented during the HIW at ICFP 2016, and ICFP 2017, I’ve been spending a some time on an alternative llvm backend. GHC used LLVM as an external tool, and communicates with LLVM via LLVMs Intermediate Representation. For this the LLVM backend in GHC (via `-fllvm`) writes out text files containing the textual LLVM IR, and feeds those into LLVMs the `opt` and `llc` tools to produce the final machine code. The textual IR has been changing quite a bit for each release in the past. But seems to have been quite stable from LLVM3.9 through LLVM4 and now LLVM5. However LLVM also has a binary IR called LLVM Bitcode, which is a very stable format and the one they advise to work against. Sadly, the documentation on it is mostly contained in the BitcodeReader and BitcodeWriter C++ files from the LLVM project. As Cmm hands out only labels for function without function signatures, and the LLVM backend wants to be a good consumer, we assume functions to always be pointers to int8 (i8*), as LLVM expects them to be properly typed. Of course when defining functions we do have the full function signature and also need it to pass arguments. Yet to make i8* assumption work, we create aliases for each function we define, that are of type i8*. On macOS (and iOS) where the mach-o format is used, the linker uses a feature called `subsections_via_symbols` to strip dead code. This works, by assuming that all code between two symbols belongs to the first symbol. GHCs use of Tables Next To Code, and the `prefixdata` feature that was added to llvm just for this purpose however put data in front of symbols, and the linker will strip that data if it determines the previous symbol is not used. Thus we can not strip any code on macOS or iOS produced by GHC. The NCG inserts `$dsp` suffix symbols in front of the TNTC data, and marks those as used, to work around the dead-strip issue. The current llvm backend uses the LLVMManger to strip out the `.symbols_via_subsections` directive from the generated assembly prior to handing it off to the assembler. I therefore sat out to try and see if I could fix some of the issues we ran into. This has lead to building three libraries: - data-bitcode (github.com/angerman/data-bitcode) A bitcode reader/writer. In itself Bitcode is a rather simple encoding format. It is based on sequences of bits as opposed to bytes. And encoded so called blocks (with IDs), that can give meaning to records (think: structs) that are in those blocks. It also comes with a compression mechanism, where one can define so called abbreviated records (think: packed structs). - data-bitcode-llvm (github.com/angerman/data-bitcode-llvm) A package to model LLVM modules, and lower them into the bitcode AST - data-bitcode-edsl (github.com/angerman/data-bitcode-edsl) A Haskell EDSL, that allows to construct LLVM modules. E.g. testModule :: Module testModule = mod "undef" [ def "main" ([i32, ptr =<< i8ptr] --> i32) $ \[ argc, argv ] -> mdo block "entry" $ do mem <- undef =<< (arr 10 =<< i8) memG <- global (mutable . private) "mem" mem ptr <- gep memG =<< sequence [int32 0, int32 0] memset <- fun "llvm.memset.p0i8.i32" =<< [i8ptr, i8, i32, i32, i1] --> void ccall memset =<< (ptr:) <$> sequence [ int8 0, int32 10, int32 4, int 1 0 ] ret =<< int32 0 pure () ] More examples can be found in github.com/angerman/data-bitcode-edsl/blob/master/test/EDSLSpec.hs With this in hand, I went a head and ported the existing llvm code gen to use the EDSL instead of concatenating strings. After this introduction, I’m now pleased to inform you that the `llvmng` backend now passes fast and slow validation, with the exception of the peculiar case of T6084 (ghc.haskell.org/t/6084) where the callee and caller signatures do not match up, and this causes the `llvmng` backend to topple over. Another note is in order: the llvmng backend is currently quite a bit more memory hungry and time consuming than the current llvm backend for non trivial modules. We do get dead-strippable binaries through (for `main = putStrLn “hello world”`): 1.2M Main8.2-llvm 972k MainHEAD-llvmng The relevant code can be found in github.com/zw3rk/ghc/tree/llvm-ng Cheers, Moritz Validation Results Below: fast validation: Unexpected results from: TEST="MultiLayerModules T12707 T13379 T13701 T13719 T6084 T9630" SUMMARY for test run started at Tue Sep 19 12:53:34 2017 +08 0:08:06 spent to go through 6077 total tests, which gave rise to 23781 test cases, of which 16423 were skipped 17 had missing libraries 2392 expected passes 32 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 6 unexpected stat failures Unexpected failures: codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) Unexpected stat failures: perf/compiler/T13379.run T13379 [stat not good enough] (llvmng) perf/compiler/T9630.run T9630 [stat not good enough] (llvmng) perf/compiler/T12707.run T12707 [stat not good enough] (llvmng) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (llvmng) perf/compiler/T13719.run T13719 [stat not good enough] (llvmng) perf/compiler/T13701.run T13701 [stat not good enough] (llvmng) slow validation: Unexpected results from: TEST="MultiLayerModules T12707 T13379 T13701 T13719 T6084 T9630" SUMMARY for test run started at Tue Sep 19 13:14:18 2017 +08 0:28:57 spent to go through 6077 total tests, which gave rise to 23908 test cases, of which 16302 were skipped 69 had missing libraries 6223 expected passes 72 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 3 unexpected failures 12 unexpected stat failures Unexpected failures: codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) codeGen/should_run/T6084.run T6084 [exit code non-0] (llvmng) Unexpected stat failures: perf/compiler/T13379.run T13379 [stat not good enough] (llvmng) perf/compiler/T13379.run T13379 [stat not good enough] (llvmng) perf/compiler/T9630.run T9630 [stat not good enough] (llvmng) perf/compiler/T12707.run T12707 [stat not good enough] (llvmng) perf/compiler/T9630.run T9630 [stat not good enough] (llvmng) perf/compiler/T12707.run T12707 [stat not good enough] (llvmng) perf/compiler/T13719.run T13719 [stat not good enough] (llvmng) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (llvmng) perf/compiler/T13701.run T13701 [stat not good enough] (llvmng) perf/compiler/T13719.run T13719 [stat not good enough] (llvmng) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (llvmng) perf/compiler/T13701.run T13701 [stat not good enough] (llvmng)

1 0

A type checker plugin for row types
by Nicolas Frisby 18 Sep '17

18 Sep '17

Hi all. I've been spending my free time for the last couple months on a type checker plugin for row types. The free time waxes and wanes; sending an email like this one was my primary goal for the past couple weeks. At the very least, I hoped this project would let me finally get some hands on experience with OutsideIn. And I definitely have. But I've also made more progress than I anticipated, and I think the plugin is starting to have legs! I haven't uploaded the code yet to github -- it's not quite ready to share. But I did do a write up on the dev wiki. https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain I would really appreciate and questions, comments, and --- boy, oh boy --- answers. I hope to upload within a week or so, and I'll update that wiki page and reply to this email when I do. Thanks very much. -Nick P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically interested in this (e.g. plugins, row types, etc). Please feel free to forward to others that come to mind; I know some inboxes abjectly can't afford default list traffic. P.P.S. -- One hold up for the upload is: which license? I intend to release under BSD3, mainly to match GHC since one ideal scenario would involve being packaged with/integrated into GHC. But my brief recent research suggests that the Apache license might be more conducive to eventual widespread adoption. If you'd be willing to advise or even just refer me to other write ups, please feel free to email me directly or to start a separate thread on a more appropriate distribution list (CC'ing me, please). Thanks again.

8 16

-0 rational?
by Moritz Angermann 18 Sep '17

18 Sep '17

Hi *, I just ran into the following case: > fromRat (-0 :: Rational) :: Double 0.0 > -0 :: Rational 0 % 1 How do I encode negative zero as a rational? The question come up as `CmmFloat` is defined as `CmmFloat Rational Width` in compiler/cmm/CmmExpr.hs. And my code generator thus turned (Int, Rational) into a floating point expression, and when trying to turn it into a `double` value, I ended up getting bad negative zeros. This makes me believe I can’t actually encode `-0` as a Rational, and such `CmmFloat` will never contain `-0`? Cheers, Moritz

2 1