RE: patch applied (ghc): TickBox representation change

...
|         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