[GHC] #15192: Refactor of Coercion

[GHC]

#15192: Refactor of Coercion
-------------------------------------+-------------------------------------
        Reporter:  ningning          |                Owner:  ningning
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4747
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by ningning):

 Replying to [comment:25 simonpj]:
 > Ningning, let me check my understanding
 >
 > * In HEAD we have `GRefl` but not `CoherenceCo`
 >
 > * In EXPERIMENT you added `CoherenceCo` and used it.
 >
 > * You found that EXPERIMENT allocated up to 2.5% less.
 >
 > Right so far?

 The change of {{{homogenise_result}}} saves ~2.5%. With more similar
 changes the allocation could become fewer.

 For example, a similar change in {{{TcFlatten.flatten_args_slow}}} (use
 {{{mkTcCoherenceLeftCo'}}} instead of {{{mkTcCoherenceLeftCo}}} saves ~1%
 in T9872d. Namely, if we combine those two changes, it saves ~3.5%.

 Changes in other places does not have a significant result in T9872d
 though.

 > What are the costs of EXPERIMENT?
 >
 > * The extra constructor in Coercion, and extra cases in free-vars,
 substitution, pretty-printing etc.
 >
 > * Extra stuff in `OptCoercion`, I assume.  This is already a very tricky
 module, so may be the biggest cost.
 >
 > Is that all?

 Extra stuff in the compilation pipeline, including {{{Coercion}}},
 {{{OptCoercion}}}, {{{CoreLint}}}, {{{Ifacexxx}}} etc.  Basically I
 recovered everything I have removed of {{{CoherenceCo}}} in previous
 commit. Except that, I added nothing new.

 > Other thoughts
 >
 > * I recall that `CoerherenceCo` was biased to the laft. One could add a
 right-biased version too -- would that help even more?

 I don't know the answer for sure. But I guess not. As
 {{{mkCoherenceRightCo}}} differs from {{{CoherenceCo}}} only by 2
 {{{SymCo}}}, which won' save much I presume. In contrast, the
 {{{GRefl}}}-version of {{{mkCoherenceLeftCo}}} differs from
 {{{CoherenceCo}}}-version of {{{mkCoherenceLeftCo'}}} by a whole type, and
 the type can be large.

 > * Are you implicitly advocating adding `CoherenceCo` not for
 expressiveness but for efficiency?  And if so, are there any other
 combinations of coercions that we could play a similar game with?

 No I am not advocating addting `CoherenceCo` back.
 I don't know if it is worth it to add all those stuff for one particular
 test case.

 If we look through `Coercion.hs` in head, we can find that functions
 `mkCoherenceLeftCo` and `mkCoherenceRightCo` are utility functions that
 construct coercions and are used frequently but don't have their own
 constructor of coercion (namely, `CoherenceCo`). Other ones don't seem to
 need a new constructor. (`castCoercionKind` could be one, but I don't
 think it will benefit from a new constructor of coercion).

 > * I've noticed (in `tc_trace` printing) that we build a LOT of Refl
 coercions.  Yet the `isGReflCo` case obviously doesn't fire, perhaps
 because the coercion hasn't been zonked.  Yet in fact `zonkTcType`
 ''does'' zonk coercions, so I'm a bit puzzled about why we get quite so
 many of them.  There might be some low-hanging fruit in finding out why.
 >
 > * In writing that comment I ''also'' realised that when zonking a type
 (with `zonkTcType`) we fully zonk all the coercions it mentions.  I wonder
 if that is really necessary?  That is, in `zonkTcType` could we simply
 not-zonk any coercions, just doing the latter when we do
 `zonkTcTypeToType`?

 I am not familiar with the zonking process (yet). If there are some other
 ways to improve the performance that would be great.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15192#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler