Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler |Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonpj): * status: closed = new * resolution: wontfix = Comment: I'm re-opening this, since it came up again in #7378. I wonder if a very simple pass, enabled with -O2, might be worth while. No overflow magic, just simple comparisons. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler |Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by simonpj): * priority: lowest = normal * milestone: 7.6.2 = _|_ -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler |Version: 6.8.2 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by michalt): Yes, that makes sense. Also the plugin is on github if anyone is interested: https://github.com/michalt/ghc-comparisons-plugin -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler |Version: 6.8.2 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by igloo): * status: patch = closed * resolution: = wontfix Comment: If the idea is to implement it as a plugin separate from GHC, then I think we should close the ticket. Thanks for all your work on this though, michalt. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.1 Component: Compiler |Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by michalt): Replying to [comment:26 simonmar]: C/C++ compilers use abstract interpretation to do this, e.g. [http://en.wikipedia.org/wiki/Sparse_conditional_constant_propagation]. This could be expressed very nicely as a Hoopl optimisation, which would deal nicely with loops too. However, at the Hoopl level we would only be able to optimise within a single function or closure, whereas doing this at the Core level has far greater reach. Right, using abstract interpretation would definitely find more optimization opportunities. I might look into that if I have some more free time. Also, I think that doing it on a level of C-- or in a C/C++ compiler would require some relational abstract domain (e.g., octagons), right? AFAIK SCCP would only be able to optimize conditions if the values are actually constant. Are C/C++ compilers actually doing any relational analysis (apart from things like Graphite in GCC or Polly in LLVM)? I don't have any specific comments about this particular implementation - there's a lot of code and I haven't fully reviewed it. I still think the best way forward is for this to be a plugin; I think all the infrastructure is in place to make this work. Now that I think about, you're probably right -- I'll refactor it into a GHC plugin and upload to github and hackage. Not sure if you want to keep the ticket open... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.6.1 Component: Compiler |Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Comment(by simonmar): C/C++ compilers use abstract interpretation to do this, e.g. [http://en.wikipedia.org/wiki/Sparse_conditional_constant_propagation]. This could be expressed very nicely as a Hoopl optimisation, which would deal nicely with loops too. However, at the Hoopl level we would only be able to optimise within a single function or closure, whereas doing this at the Core level has far greater reach. I don't have any specific comments about this particular implementation - there's a lot of code and I haven't fully reviewed it. I still think the best way forward is for this to be a plugin; I think all the infrastructure is in place to make this work. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons
--+-
Reporter: simonpj | Owner:
Type: bug | Status: patch
Priority: lowest | Milestone: 7.6.1
Component: Compiler |Version: 6.8.2
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Changes (by michalt):
* status: new = patch
Comment:
I think I've fixed the problem with shadowing (I've basically followed the
approach used in CSE). Everything validates.
However, the nofib results are not very encouraging (I've attached the
whole
output of ```nofib-analyse```):
{{{
Program SizeAllocs Runtime Elapsed TotalMem
...
Min -0.1% -0.0% -3.5% -3.8% -4.8%
Max +0.4% +0.0% +2.0% +2.0% +0.0%
Geometric Mean -0.0% -0.0% -1.0% -1.0% -0.1%
}}}
(the results are: clean GHC and ordinary nofib run vs GHC with the patch
and
nofib run with EXTRA_HC_OPTS=-fcomparisons).
I've used the debugging output to see how often the optimization is
actually
removing some comparison: in case of GHC compile it managed to remove
around
1800 comparisons, in nofib only around 40. So I'm not sure this is worth
the
whole additional optimization. It seems that either the patch is not going
far
enough or there simply isn't that many opportunities for optimization...?
If it's
the former, then the main idea would probably be to extend the pass to be
able
to deal with arithmetic [1]. If it's the latter then maybe we should just
close
it as wontfix? What do you think?
[1] Handling, for example things like:
{{{
case x # y + 5 of
case x # y + 4 of
...
}}}
but this will be quite a bit more complex as we need to take into account
integer overflows, etc.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:25
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.4.1 Component: Compiler |Version: 6.8.2 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --+- Comment(by simonpj): Also it'd be good to do a nofib run to see what performance boost you get -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.4.1 Component: Compiler |Version: 6.8.2 Resolution: | Keywords: Testcase: | Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --+- Changes (by michalt): * owner: simonpj = * status: patch = new Comment: The patch doesn't take into account variable shadowing --- I'll try to fix that once I have some more time. I've never noticed any problems probably because simplifier removes (most of) it and the optimization fires only in pretty special cases (nested comparisons, no arithmetic).. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: simonpj Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by simonmar): Another thought: this can be a plugin, and shipped via Hackage, right? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: simonpj Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by michalt): Replying to [comment:20 simonmar]: Another thought: this can be a plugin, and shipped via Hackage, right? (I'm assuming you're referring to the optimization, not the idea of sub- rules) Yes it could be made a plugin. Although I'm not sure it would be used by anyone then (personally I use Hackage only when I need some library, etc. and probably wouldn't have thought to search for compiler optimization, unless it is something really huge). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons
-+--
Reporter: simonpj |Owner: simonpj
Type: bug | Status: patch
Priority: low |Milestone: 7.4.1
Component: Compiler | Version: 6.8.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Changes (by basvandijk):
* cc: v.dijk.bas@… (added)
Comment:
Would it be hard to extend the language of RULES so that a user can
perform this optimization instead of the compiler? I'm thinking about
something like this:
{{{
{-# RULES
forall x y t f.
(case (x # y) of
True - t
False - f
)
=
(case (x # y) of
True - t {{(x ==# y)=False}}
False - f
)
#-}
}}}
The `v {{subrules}}` syntax assigns ''sub-RULES'' to the variable `v`.
`subrules` is a list of RULES of the form `p1 = e1, p2 = e2 ... pn = en`
which are applied to the expression that `v` refers to.
I think it would be nice if sub-RULES have the same (or a very similar)
syntax that normal RULES have. They should even be able to quantify new
variables.
The way I expect this to be used most often is that the sub-RULES describe
the actual substitutions while the ''top-level'' RULE only describes
context. However it should be possible that both the top-level and the
sub-rules describe transformations.
This probably deserves its own ticket so I stop now.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:17
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: simonpj Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by michalt): Replying to [comment:17 basvandijk]: Would it be hard to extend the language of RULES so that a user can perform this optimization instead of the compiler? .. Note that this optimization goes a bit further than your example. For instance, once it knows `x # y` and `y =# z` it can optimize away `x # z`. Similarly knowing `x # 100` and `y # 10` it can get rid of `x ==# y`. That would be probably quite difficult to do with rules (even extended). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons
-+--
Reporter: simonpj |Owner: simonpj
Type: bug | Status: patch
Priority: low |Milestone: 7.4.1
Component: Compiler | Version: 6.8.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Comment(by basvandijk):
Replying to [comment:18 michalt]:
Note that this optimization goes a bit further than your example. For
instance, once it knows `x # y` and `y =# z` it can optimize away `x
# z`.
This is possible with sub-rules:
{{{
{-# RULES
forall x y t f.
(case (x # y) of
True - t
False - f
)
=
(case (x # y) of
True - t {{ forall z t2 f2.
(case (y =# z) of
True - t2
False - f2
)
=
(case (y =# z) of
True - t2 {{(x # z)=False}}
False - f2
)
}}
False - f
)
#-}
}}}
Similarly knowing `x # 100` and `y # 10` it can get rid of `x ==# y`.
That would be probably quite difficult to do with rules (even extended).
Encoding it for the concrete `100` and `10` is easy. However encoding it
for all numbers is not possible without having the ability to reason about
numbers in the language of RULES.
I'm sure your patch is way more powerful since I expect it will have this
ability. I do wonder if sub-rules have other useful applications?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:19
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by simonmar): Wow, there's quite a lot of code here. Simon: we need to review and decide what to do. Somehow this optimisation feels similar to what the simplifier already does with case expressions (eliminating redundant cases, and branches that can't match), and perhaps it ought to be incorporated into the simplifier. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Comment(by tibbe): It's also similar to what a forward substitution pass at a lower level might do. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: simonpj Type: bug | Status: patch Priority: low |Milestone: 7.4.1 Component: Compiler | Version: 6.8.2 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: Runtime performance bug -+-- Changes (by igloo): * owner: = simonpj -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons
-+--
Reporter: simonpj |Owner:
Type: bug | Status: patch
Priority: low |Milestone: 7.4.1
Component: Compiler | Version: 6.8.2
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
-+--
Changes (by michalt):
* status: new = patch
Comment:
Attached is my initial implementation of a core-to-core pass that tries to
optimize away unnecessary comparisons. Right now it is able to handle code
like:
{{{
case x y of
True - .. case y = z of
True - .. x == z .. -- always false
}}}
or
{{{
case x 10 of
True - .. case y 20 of
True - .. x == y .. -- always false
.. x 15 .. -- always false
}}}
It basically stores the relations between variables and their intervals
and uses
both to determine if a result of some comparison is known. So far it does
not
handle complex expressions (like anything that includes arithmetic), so:
{{{
case x + 10 y - 3 of
True - .. x y .. -- always false but not handled
}}}
It also doesn't handle the second example in the ticket description.
The patch validates (i.e. I've compiled stage2 and libraries with the new
optimization and it validates). I've also run nofib but I haven't noticed
anything that really stands out (it does find some more than 60
unnecessary
comparisons in nofib and in case of GHC/libraries more than 100).
So what do you think about it? Let me know what should be fixed/changed
etc.
Also I didn't write any tests yet, since I'm not sure how to actually test
it
--- would it be enough to simply write a few cases where the optimization
should
fire and some where it shouldn't and then just make sure that the result
is
as expected?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:13
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons -+-- Reporter: simonpj |Owner: Type: run-time performance bug | Status: new Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * milestone: 6.10 branch = 6.12 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal| Milestone: 6.10 branch Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: 6.10.1 = 6.10 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal| Milestone: 6.10.1 Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: 6.8.3 = 6.10.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2132: Optimise nested comparisons
#2132: Optimise nested comparisons --+- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal| Milestone: 6.8.3 Component: Compiler |Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * milestone: = 6.8.3 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2132#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
