> On May 31, 2017, at 5:21 PM, Ryan Scott <[email protected]> wrote:
> Does you know what might be going on here?
I think so, but I don't know how to fix it.
The commit you found (thank you!) makes simple_opt_expr (the "simple
optimizer", run directly after desugaring, even with -O0) a little more
selective in what `case` expressions it throws away. Previous to that commit,
the optimizer would throw away a `case error "deferred type error" of _ -> ...`
which is terrible. It seems that you have discovered that we are now too timid
in throwing away unhelpful cases. It would be interesting to know what the
newly-retained cases look like, so that we might throw them away.
But there remains a mystery: Why do we need this code at all? Reading Note
[Getting the map/coerce RULE to work] closely, it seems we need to simplify
forall a b (co :: a ~R# b).
let dict = MkCoercible @* @a @b co in
case Coercible_SCSel @* @a @b dict of
_ [Dead] -> map @a @b (\(x :: a) -> case dict of
MkCoercible (co :: a ~R# b) -> x |> co) = let dict = ... in ...
to
forall a b (co :: a ~R# b).
map @a @b (\(x :: a) -> x |> co) = \(x :: [a]) -> x |> [co]
Part of doing so is to drop the `case Coercible_SCSel ...`, which gets in the
way. The mystery is why this needs special code -- shouldn't the
eliminate-case-of-known-constructor do the trick? This would require unfolding
Coercible_SCSel. Does that happen? It would seem not... but maybe it should,
which would remove the special-case code that I changed in that commit, and
quite likely would simplify much more code besides.
So: Is Coercible_SCSel unfolded during simple_opt? If not, what wonderful or
terrible things happen if we do? If so, why does case-of-known-constructor not
work here? My guess is that answering these questions may solve the original
problem, but this guess could be wrong.
Richard
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
