Opened 17 months ago

Last modified 9 months ago

#15090 new task

Do more coercion optimisation on the fly

Reported by: simonpj Owned by:
Priority: normal Milestone: 8.10.1
Component: Compiler Version: 8.2.2
Keywords: Coercions Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by simonpj)

When studying #15019, I looked at CoreOpt.pushCoValArg. I saw lots of attempted decompositions in pushCoValArg, which were trying to do decomposeFunCo on

    C @g1 ; sym (C @g2)
where
    axiom C a = a -> a

But the smart mkNthCo can't make progress on this, so we get

   Nth:2 (C @g1 ; sym (C @g2))

and these things stack up if there is a chain of applications in Simplify.simplCast.

The coercion optimiser will optimise this coercion to

   (g1 ; sym g2) -> (g1 ; sym g2)

and now the smart mkNthCo in decomposeFunCo will succeed.

Possible idea: make this optimization part of mkTransCo so that it happens on the fly.

(Annoyingly, I can't remember which of the three test cases mentioned in #15109 displayed this behaviour.)

Change History (4)

comment:1 Changed 17 months ago by tdammers

I tried to figure out how to do this, but I'm a bit confused - mkTransCo takes two coercions and builds a TransCo from them, but IIUC, the optimisation we're talking about should detect suitable NthCo's and turn them into AppCos. So I don't quite understand why this needs to be done in mkTransCo rather than mkNthCo. Or should mkTransCo drill down into its arguments and perform the optimisation on those?

comment:2 Changed 17 months ago by simonpj

Description: modified (diff)

comment:3 Changed 15 months ago by bgamari

Milestone: 8.6.18.8.1

These won't be addressed by GHC 8.6.

comment:4 Changed 9 months ago by osa1

Milestone: 8.8.18.10.1

Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.