...
| case tick<n> of
| DEFAULT -> e
|
| does exactly the Right Thing!
That makes sense, ok.
| * We need have binary tick boxes so that we can have accurate branch
| counts, because I want to use this
| information for optimization purposes later. Can imagine the inliner
| using Hpc information to drive inlining :-)
| The problem that
|
| tick<n> True
|
| Is CAF-able. So
|
| case expr of
| True -> tick<n> True
| False -> tick<n> False
I do not buy this argument. After all in
case tick<n> of DEFAULT -> e
the tick<n> is CAFable too! But it is not floated out. Why not? Because it
is a "trivial expression" (see CoreUtils.exprIsTrivial).
So all we need do is make (tick<n> e) trivial if e is trivial. Which you
probably want anyhow. Example:
let x = tick<n> f in ....
You probably would be happy to replace every occurrence of x by (tick<n> f)
wouldn't you? Or not?
Even if not, floating will not float out expressions that are "cheap" (see
CoreUtils.exprIsCheap). So you could make (tick<n> e) cheap, even if not
trivial.
I think it's worth following this up; if you could eliminate binary tick-boxes
that would be a good step forward.
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
