patch applied (ghc): TickBox representation change
simonpj at microsoft.com
Fri Dec 8 10:48:54 EST 2006
| 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.
More information about the Cvs-ghc