- ghc-devs - Haskell.org

Re: Performance of pattern checker on OptCoercions
by Thomas Miedema 20 Dec '15

20 Dec '15

> I have a small question though: do we need the opposites too (I mean > `-fno-full-guard-reasoning` and ` -Wtoo-many-guards`)? I cannot think of > a scenario where we do or am I missing something? > A scenario where `-fno-full-guard-reasoning` could be useful: you add `-ffull-guard-reasoning` to ghc-options in your .cabal file, but switch it off in an OPTIONS_GHC pragma in a specific file. But `-f` and `-W` flags always come in pairs, so that is easy. You would add `-Wtoo-many-guards` to `standardWarnings` in compiler/main/DynFlags.hs. Others? If I get the green light, this is a matter of minutes to change :) > If it is not too much trouble, please submit your patch to Phabricator. Then others can review, and harbormaster can validate it.

1 0

Re: Performance of pattern checker on OptCoercions
by Richard Eisenberg 20 Dec '15

20 Dec '15

I hereby abstain from debating the color on this particular bikeshed. My taste in bikeshed colors has proven to be unreliable. Richard On Dec 19, 2015, at 5:32 PM, George Karachalias <george.karachalias(a)gmail.com> wrote: > Hi Thomas, > > On Sat, Dec 19, 2015 at 8:36 PM, Thomas Miedema <thomasmiedema(a)gmail.com> wrote: > Hi George, > > here is an even simpler design! > > When `-ffull-guard-reasoning` is on, use the new pattern match checker. > > When `-ffull-guard-reasoning` is off (the default), try to use the new pattern match checker, but if the number of guards is more than 20, > 1. fall back to the old (simple) pattern match checker, and > 2. issue a `too-many-guards` warning > > The warning can be turned off with `-Wno-too-many-guards`. > > What do you think? > > Sounds nice and easy to change :) > I have a small question though: do we need the opposites too (I mean > `-fno-full-guard-reasoning` and ` -Wtoo-many-guards`)? I cannot think of > a scenario where we do or am I missing something? > > Others? If I get the green light, this is a matter of minutes to change :) > > George > > -- > things you own end up owning you

1 0

Re: Performance of pattern checker on OptCoercions
by Richard Eisenberg 19 Dec '15

19 Dec '15

On Dec 13, 2015, at 1:07 PM, George Karachalias <george.karachalias(a)gmail.com> wrote: > Sounds nice and I think it is much better than giving up guards completely. The only thing I > don't like much is having so many different flags concerning the check because I don't want > it to become "too complex" for users. I guess we have to live with it though :) Yes. I'd like this to be simpler. Perhaps there is a way to combine all of this into one flag. I see 4 settings: 1. No guard match checking. 2. Check guards; bail and issue warning on tough cases. 3. Check guards; bail with no warning on tough cases. 4. Check guards at any cost. We could have these be 1. -fwarn-pattern-guards=none 2. -fwarn-pattern-guards=try 3. -fwarn-pattern-guards=try-quiet 4. -fwarn-pattern-guards=do -- there is no "try" Is that simpler? Maybe. Richard

2 2

arc land changes author
by Joachim Breitner 19 Dec '15

19 Dec '15

Hi, I was just about to apply a DR by David. First I ran $ arc patch D390 which put me on a feature branch. Then I reworded the commit with $ git commit --amend and then I tried to land it with $ arc land Luckily I also passed --hold... It even asked me if I want to land the commit although I am not the author: This branch has revision 'D390: Reorder GHC.List; fix performance regressions' but you are not the author. Land this revision by dfeuer? [y/N] y But it still put me in the author field: $ git show HEAD commit a387c359b99667ce55016de3816b5d9873a155db Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Wed Oct 29 08:17:05 2014 +0100 Reorder GHC.List; fix performance regressions Summary: Rearrange some oddly placed code. (and undid my commit message changes....) Did I do something wrong? Anyways, it said something along the lines of Cleaning up feature branch... (Use `git checkout -b 'arcpatch-D390' 'a3ceb0e7f44d53f728fb8bd0dfb4c97297818029'` if you want it back.) so with $ git commit --amend -C a3ceb0e7f44d53f728fb8bd0dfb4c97297818029 I was able to get the edited commit message with the right author back. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

ghc-split??
by Simon Peyton Jones 18 Dec '15

18 Dec '15

I’m getting this with a clean HEAD on Linux. Any ideas? Simon ghc-stage1: could not execute: /5playpen/simonpj/HEAD-4/inplace/lib/bin/ghc-split make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1

3 4

Re: Performance of pattern checker on OptCoercions
by Richard Eisenberg 17 Dec '15

17 Dec '15

On Dec 17, 2015, at 1:31 PM, George Karachalias <george.karachalias(a)gmail.com> wrote: > > My single last concern is what I wrote earlier: "Flags 2 and 3 are a bit tricky: Actual bailing > will uglify the code and make it much more complicated so I would prefer in practice to just > check up front with a good metric whether the possibility to be non-performant is high and in > these cases just not call the checker at all." > > If we agree on this one, I am gonna wrap it up in the next 2 days. :-) I'm quite happy with this. My thought is that if it's a bit wrong, that's OK -- we'll refine the settings over time. Others? Richard

1 0

Re: Performance of pattern checker on OptCoercions
by Richard Eisenberg 17 Dec '15

17 Dec '15

On Dec 17, 2015, at 8:15 AM, George Karachalias <george.karachalias(a)gmail.com> wrote: > What do you think? I have already implemented a first patch with two options: If the number of > guards is small run the check and say nothing. If not, check for 2 possible flags: > -fwarn-pattern-guards ==> Give it your best > -fwarn-ignore-pattern-guards ==> Do not run the check on the cases with many guards without a warning > None of the two enabled? ==> Give a warning of the form: > > T783.hs:4:1: warning: > Pattern match checking failed for an equation for foo > due to the big number of guards > (Use -fwarn-ignore-pattern-guards if you want to hide this message > or -fwarn-pattern-guards if you want the checker to run no matter what) I don't have much comment on your implementation techniques, as I don't know this end of the operation well enough to have an opinion. For the point above: what if both flags are enabled? Richard

1 0

question about coercions between primitive types in STG level
by Ömer Sinan Ağacan 17 Dec '15

17 Dec '15

Hi all, In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe coercions at the STG level. It works fine for lifted types, but for unlifted ones I'm having some problems. What I'm trying to do is given a number of primitive types I'm finding the one with biggest size, and then generating a constructor that takes this biggest primitive type as argument. The problem is that this is not working very well - GHC is generating illegal instructions that try to load a F32 value to a register allocated for I64, using movss instruction. CoreLint is catching this error and printing this: Cmm lint error: in basic block c1hF in assignment: _g16W::I64 = 4.5 :: W32; // CmmAssign Reg ty: I64 Rhs ty: F32 So I have two questions about this: 1. Is there a way to safely do this? What are my options here? What I'm trying to do is to use a single data constructor field for different primitive types. The field is guaranteed to be as big as necessary. 2. In the Cmm code shown above, the type annotation is showing `W32` but in the error message it says `F32`. I'm confused about this, is this error message given because the sizes don't match? (64bits vs 32bits) Why the type annotation says W32 while the value has type F32? Thanks..

5 8

GHC 8.0 feature freeze imminent
by Ben Gamari 17 Dec '15

17 Dec '15

Hello GHCers, Last Friday Richard Eisenberg's long-awaited no-kinds branch landed in `master`. Being one of the defining features of the 8.0 release, we bent the feature freeze schedule (initially slated for sometime last week) a bit to accomodate this piece of work. Now that Richard's work is in, we will set the official freeze date for Monday December 21st so that there is time to review and merge some queued work which we've been queuing for after the no-kinds merge. If you have work still outstanding then you should talk to either me or Austin ASAP if you have not done so already. We will be discussing the release schedule for 8.0 during the GHC today. Cheers, - Ben

4 5

Harbormaster acting up?
by Richard Eisenberg 17 Dec '15

17 Dec '15

Hi devs, Is Harbormaster acting up? I saw today two out-of-memory failures, including this one (https://phabricator.haskell.org/harbormaster/build/9150/) which happens when building the stage-1 compiler. That means that an off-the-shelf GHC is the one that's running out of memory. Separately, a comments-only patch didn't validate (https://phabricator.haskell.org/harbormaster/build/9148/) Any hints? Thanks! Richard

2 1