#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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
