[GHC] #10555: RULE left-hand side too complicated to desugar
GHC
ghc-devs at haskell.org
Tue Jul 28 21:38:59 UTC 2015
#10555: RULE left-hand side too complicated to desugar
-------------------------------------+-------------------------------------
Reporter: yongqli | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.2-rc1
Resolution: duplicate | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case: yes
Blocked By: | Blocking:
Related Tickets: #10699 | Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by simonpj):
I did look at the "lhs too complicated to desugar" issue. There's a good
reason for it, and I'm not sure what to do.
The issue is this. Most numeric primops are pure and can't fail, so they
can be subject to aggressive code motion. Division, unlike most numeric
primops, can fail. So GHC restricts its code motion by `case`-binding it.
In particular something like
{{{
a /## (b /## c)
}}}
doesn't obey the "let/app invariant" (see `CoreSyn.hs`) and gets turned
into
{{{
case b /## c of r -> a /## r
}}}
But the LHS of a rule is supposed to look like `f e1 .. en`.
Maybe the let/app invariant is too strong -- after all, we only support
imprecise exceptions for things like divide-by-zero. But if you say
{{{
if x >## 3## then
y /## x
else ...
}}}
you jolly well don't expect the `(y /## x)` to be executed until after
testing `x >## 3`, so we need to restrict code motion.
Not clear what to do here. Avoid division primops on the LHS of a rule!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10555#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list