- Glasgow-haskell-users

CMM-to-ASM: Register allocation wierdness
by Harendra Kumar 26 Jun '16

26 Jun '16

Hi, I am implementing unicode normalization in Haskell. I challenged myself to match the performance with the best C/C++ implementation, the best being the ICU library. I am almost there, beating it in one of the benchmarks and within 30% for others. I am out of all application level tricks that I could think of and now need help from the compiler. I started with a bare minimum loop and adding functionality incrementally watching where the performance trips. At one point I saw that adding just one 'if' condition reduced the performance by half. I looked at what's going on at the assembly level. Here is a github gist of the assembly instructions executed in the fast path of the loop, corresponding cmm snippets and also the full cmm corresponding to the loop: https://gist.github.com/harendra-kumar/7d34c6745f604a15a872768e57cd2447 I have annotated the assembly code with labels matching the corresponding CMM. With the addition of another "if" condition the loop which was pretty simple till now suddenly got bloated with a lot of register reassignments. Here is a snippet of the register movements added: # _n4se: # swap r14 <-> r11 => 0x408d6b: mov %r11,0x98(%rsp) => 0x408d73: mov %r14,%r11 => 0x408d76: mov 0x98(%rsp),%r14 # reassignments # rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx => 0x408d7e: mov %rbx,0x90(%rsp) => 0x408d86: mov %rcx,%rbx => 0x408d89: mov %rdx,%rcx => 0x408d8c: mov %rsi,%rdx => 0x408d8f: mov %rdi,%rsi => 0x408d92: mov %r8,%rdi => 0x408d95: mov %r9,%r8 => 0x408d98: mov %r10,%r9 => 0x408d9b: mov 0x90(%rsp),%r10 . . . loop logic here which uses only %rax, %r10 and %r9 . . . . # _n4s8: # shuffle back to original assignments => 0x4090dc: mov %r14,%r11 => 0x4090df: mov %r9,%r10 => 0x4090e2: mov %r8,%r9 => 0x4090e5: mov %rdi,%r8 => 0x4090e8: mov %rsi,%rdi => 0x4090eb: mov %rdx,%rsi => 0x4090ee: mov %rcx,%rdx => 0x4090f1: mov %rbx,%rcx => 0x4090f4: mov %rax,%rbx => 0x4090f7: mov 0x88(%rsp),%rax => 0x4090ff: jmpq 0x408d2a The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. Maybe this is because these are reusable blocks and the movement is necessary when used in some other path? Can this be avoided? Or at least avoided in a certain fast path somehow by hinting the compiler? Any pointers to the GHC code will be appreciated. I am not yet much familiar with the GHC code but can dig deeper pretty quickly. But before that I hope someone knowledgeable in this area can shed some light on this at a conceptual level or if at all it can be improved. I can provide more details and experiment more if needed. Thanks, Harendra

5 12

TDNR without new operators or syntax changes
by Jeremy 22 Jun '16

22 Jun '16

Previous attempts to propose TDNR [1] have met with opposition over the accompanying proposal to change the syntax of the dot or add a new operator for postfix application. However, nothing about TDNR - other than certain motivating examples - actually requires changes to the syntax of Haskell or new operators. TDNR could be implemented as an extension which just give GHC a new way of disambiguating function names, and nothing else. This would still have some advantages: - Redundant module qualification no longer required. - Unqualified imports could be changed to a different module with the same interface (a very poor-man's backpack) without any other code changes. - People who want TDNR with postfix function application will only need to define a simple postfix operator. I would therefore like to propose TNDR without any syntax/prelude changes. [1] https://prime.haskell.org/wiki/TypeDirectedNameResolution -- View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-c… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 9

Simon's email classified as spam
by Simon Peyton Jones 19 Jun '16

19 Jun '16

Dear GHC devs/users This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder. Gershom thinks he’s fixed it (below). Can I trespass on your patience once more? Just let me know if this email ends up in your inbox or spam. Can you cc John and Gershom (but perhaps not everyone else)? Thanks Simon | From: Gershom B [mailto:gershomb@gmail.com] | Sent: 18 June 2016 18:53 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; John Wiegley | <johnw(a)newartisans.com> | Cc: Michael Burge <michaelburge(a)pobox.com> | Subject: Re: FW: CMM-to-SAM: Register allocation weirdness | | Simon — I just found two possible sources of the problem (first: the top | level config didn’t take hold due to other errors when updating — fixed that, | and second, it might be possible the top level config isn’t retroactively | applied to all lists — so i added the config to the relevant lists directly). | | I think if you try one more time it might work (fingers crossed).

3 2

RE: CMM-to-ASM: Register allocation wierdness
by Simon Peyton Jones 19 Jun '16

19 Jun '16

Takenobu, and others Thanks. Several people have mentioned that email from me is ending up in spam. It turns out to be a fault in the Haskell.org mailman setup, which was mis-forwarding my email. Apparently it is fixed now. If THIS message ends up in spam with a complaint like that below, could you let me know? Thanks Simon From: Takenobu Tani [mailto:takenobu.hs@gmail.com] Sent: 18 June 2016 08:18 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: CMM-to-ASM: Register allocation wierdness Hi Simon, I report to you about your mails. Maybe, your mails don't reach to Gmail users. I don't know why, but your mails have been distributed to "Spam" folder in Gmail. Gmail displays following message: "Why is this message in Spam? It has a from address in microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.c…> but has failed microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmicrosoft.c…>'s required tests for authentication." For reference, I attach the screen of my Gmail of spam folder. Recent your mails have been detected as spam. Please check your mail settings. Regards, Takenobu 2016-06-16 21:10 GMT+09:00 Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>>: | All-in-all, the graph coloring allocator is in great need of some love; | Harendra, perhaps you'd like to have a try at dusting it off and perhaps | look into why it regresses in compiler performance? It would be great if | we could use it by default. I second this. Volunteers are sorely needed. Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskel…>

4 4

Feedback on -Wredundant-constraints
by Adam Foltzer 12 Jun '16

12 Jun '16

With 8.0.1 freshly arrived, I'm taking on the task of updating a number of our larger projects here at Galois. I made a couple of these comments briefly on a relevant Trac ticket[1], but I wanted to open this discussion to a wider audience. We tend to use -Wall (and -Werror, in CI environments), and so I've had to make decisions about how to handle the new -Wredundant-constraints warnings. So far, I've come to think of it as two different warnings that happen to be combined: Warning 1: a warning for constraints made redundant by superclass relationships, and Warning 2: a warning for unused constraints Overall I'm a fan of Warning 1. It seems very much in the spirit of other warnings such as unused imports. The only stumbling block is how it affects the 3-release compatibility plan with respect to, e.g., the AMP. Most of our code targets a 2-release window, though, so in every such case it has been fine for us to simply remove the offending constraint. Warning 2 on the other hand is far more dubious to me. In the best case, it finds constraints that through oversight or non-local changes are truly no longer necessary in the codebase. This is nice, but the much more common case in our code is that we've made a deliberate decision to include that constraint as part of our API design. The most painful example of this I've hit so far is in an API of related functions, where we've put the same constraint on each function even when the implementation of that particular function might not need that constraint. This is good for consistency and forward-looking compatibility (what if we need that constraint in the next version?). The warning's advice in this case makes the API harder to understand, and less abstract (the client shouldn't care or know that f needs Functor, but g doesn't, if both will always be used in a Functor context). On another level, Warning 2 is a warning that we could have given a more general type to a definition. We quite rightly don't do this for the non-constraint parts of the type signatures, so why are we doing it for the constraints? I'm happy that Warning 1 is now around, but Warning 2 feels much more like an opinionated lint check, and I really wish it wasn't part of -Wall. [1]: https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15

5 9

Call for talks: Haskell Implementors Workshop 2016, Sep 24 (FIXED), Nara
by Edward Z. Yang 09 Jun '16

09 Jun '16

(...and now with the right date in the subject line!) Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Joachim Breitner (Karlsruhe Institut für Technologie) * Duncan Coutts (Well Typed) * Michael Snoyman (FP Complete) * Luite Stegeman (ghcjs) * Niki Vazou (UCSD) * Stephanie Weirich (University of Pennsylvania) * Edward Z. Yang - chair (Stanford University)

1 0

Call for talks: Haskell Implementors Workshop 2016, Aug 24, Nara
by Edward Z. Yang 09 Jun '16

09 Jun '16

Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Joachim Breitner (Karlsruhe Institut für Technologie) * Duncan Coutts (Well Typed) * Michael Snoyman (FP Complete) * Luite Stegeman (ghcjs) * Niki Vazou (UCSD) * Stephanie Weirich (University of Pennsylvania) * Edward Z. Yang - chair (Stanford University)

1 0

Re: TDNR without new operators or syntax changes
by Jeremy . 29 May '16

29 May '16

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.

9 15

[ANNOUNCE] GHC 8.0.1 is available!
by Ben Gamari 27 May '16

27 May '16

=============================================== The Glasgow Haskell Compiler -- version 8.0.1 =============================================== The GHC developers are very pleased to announce the release of the first new super-major version of our Haskell compiler in six years, GHC 8.0.1. This release features dozens of exciting developments including, * A more refined interface for implicit call-stacks, allowing libraries to provide more helpful runtime error messages to users * The introduction of the DuplicateRecordFields language extension, allowing multiple record types to declare fields of the same name * Significant improvements in error message readability and content, including facilities for libraries to provide custom error messages, more aggressive warnings for fragile rewrite rules, and more helpful errors for missing imports * A rewritten and substantially more thorough pattern match checker, providing more precise exhaustiveness checking in GADT pattern matches * More reliable debugging information including experimental backtrace support, allowing better integration with traditional debugging tools * Support for desugaring do-notation to use Applicative combinators, allowing the intuitive do notation to be used in settings which previously required the direct use of Applicative combinators * The introduction of Strict and StrictData language extensions, allowing modules to be compiled with strict-by-default evaluation of bindings * Great improvements in portability, including more reliable linking on Windows, a new PPC64 code generator, support for the AIX operating system, unregisterised m68k support, and significant stabilization on ARM targets * A greatly improved user's guide, with beautiful and modern PDF and HTML output * Introduction of type application syntax, reducing the need for proxies * More complete support for pattern synonyms, including record pattern synonyms and the ability to export patterns "bundled" with a type, as you would a data constructor * Support for injective type families and recursive superclass relationships * An improved generics representation leveraging GHC's support for type-level literals * The TypeInType extension, which unifies types and kinds, allowing GHC to reason about kind equality and enabling promotion of more constructs to the type level * ...and more! A more thorough list of the changes included in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.… As always, we have collected various points of interest for users of previous GHC releases on the GHC 8.0 migration page, https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0 Please let us know if you encounter anything missing or unclear on this page. This release is the culmination of nearly eighteen months of effort by over one hundred contributors. We'd like to thank everyone who has contributed code, bug reports, and feedback over the past year. It's only because of their efforts that GHC continues to evolve. How to get it ~~~~~~~~~~~~~ Both the source tarball and binary distributions for a wide variety of platforms are available at, http://www.haskell.org/ghc/ Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. The Glasgow Haskell Compiler (GHC) is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, can be found on the GHC wiki http://ghc.haskell.org/trac/ghc/wiki/Platforms Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on getting started with hacking on GHC are available from GHC's developer site, http://ghc.haskell.org/trac/ghc/ Community Resources ~~~~~~~~~~~~~~~~~~~ There are mailing lists for GHC users, develpoers, and monitoring bug tracker activity; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other Haskell and GHC-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on the #ghc and #haskell of the Freenode IRC network, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 1

Pattern synonyms and GADTs in GHC 8.0.1
by Emil Axelsson 26 May '16

26 May '16

I have a problem where a pattern synonym doesn't provide the expected type refinement in GHC 8.0.1. > {-# LANGUAGE GADTs #-} > {-# LANGUAGE PatternSynonyms #-} > > data Exp a > where > Num :: (Eq a, Num a) => a -> Exp a > Add :: (Eq a, Num a) => Exp a -> Exp a -> Exp a > > pattern NumP a = Num a > > pattern AddP :: (Num a, Eq a) => Exp a -> Exp a -> Exp a > pattern AddP a b = Add a b > > simplifyP :: Exp a -> Exp a > simplifyP (AddP a (NumP 0)) = a > simplifyP a = a This gives the error • No instance for (Eq a) arising from a pattern Possible fix: add (Eq a) to the context of the type signature for: simplifyP :: Exp a -> Exp a • In the pattern: AddP a (NumP 0) In an equation for ‘simplifyP’: simplifyP (AddP a (NumP 0)) = a If I remove the type signature for `AddP`, the code goes through. Unfortunately, in my real code I need the type signature in order to resolve overloading. GHC 7.10 didn't have this problem. Is this a bug? / Emil

2 3