[Git][ghc/ghc][wip/dmdanal-precise-exn-simpl] DmdAnal: Improve handling of precise exceptions
Sebastian Graf
gitlab at gitlab.haskell.org
Wed Apr 29 10:32:21 UTC 2020
Sebastian Graf pushed to branch wip/dmdanal-precise-exn-simpl at Glasgow Haskell Compiler / GHC
Commits:
893a9737 by Sebastian Graf at 2020-04-29T12:32:14+02:00
DmdAnal: Improve handling of precise exceptions
This patch does two things: Fix possible unsoundness in what was called
the "IO hack" and implement part 2.1 of the "fixing precise exceptions"
plan in
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions,
which, in combination with !2956, supersedes !3014 and !2525.
**IO hack**
The "IO hack" (which is a fallback to preserve precise exceptions
semantics and thus soundness, rather than some smart thing that
increases precision) is called `exprMayThrowPreciseException` now.
I came up with two testcases exemplifying possible unsoundness (if
twisted enough) in the old approach:
- `T13380d`: Demonstrating unsoundness of the "IO hack" when resorting
to manual state token threading and direct use of primops.
More details below.
- `T13380e`: Demonstrating unsoundness of the "IO hack" when we have
Nested CPR. Not currently relevant, as we don't have Nested
CPR yet.
Basically, the IO hack assumed that precise exceptions can only be
thrown from a case scrutinee of type `(# State# RealWorld, _ #)`. I
couldn't come up with a program using the `IO` abstraction that violates
this assumption. But it's easy to do so via manual state token threading
and direct use of primops, see `T13380d`. Also similar code might be
generated by Nested CPR in the (hopefully not too) distant future, see
`T13380e`. Hence, we now have a more careful test in `forcesRealWorld`
that passes `T13380{d,e}` (and will hopefully be robust to Nested CPR).
**Precise exceptions**
In #13380 and #17676 we saw that we didn't preserve precise exception
semantics in demand analysis. We fixed that with minimal changes in
!2956, but that was terribly unprincipled.
That unprincipledness resulted in a loss of precision, which is tracked
by these new test cases:
- `T13380b`: Regression in dead code elimination, because !2956 was too
syntactic about `raiseIO#`
- `T13380c`: No need to apply the "IO hack" when the IO action may not
throw a precise exception (and the existing IO hack doesn't
detect that)
Fixing both issues in !3014 turned out to be too complicated and had
the potential to regress in the future. Hence we decided to only fix
`T13380b` and augment the `Divergence` lattice with a new middle-layer
element, `ExnOrDiv`, which means either `Diverges` (, throws an
imprecise exception) or throws a *precise* exception.
See the wiki page on Step 2.1 for more implementational details:
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions#dead-code-elimination-for-raiseio-with-isdeadenddiv-introducing-exnordiv-step-21
- - - - -
30 changed files:
- compiler/GHC.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Core/Arity.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/CallArity.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/FloatOut.hs
- compiler/GHC/Core/Opt/LiberateCase.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/Types/Demand.hs
- compiler/GHC/Types/Id.hs
- compiler/GHC/Types/Id/Make.hs
- testsuite/tests/stranal/should_compile/T10482a.stderr
- testsuite/tests/stranal/should_compile/T10694.stderr
- + testsuite/tests/stranal/should_compile/T13380b.hs
- testsuite/tests/stranal/should_compile/all.T
- + testsuite/tests/stranal/should_run/T13380d.hs
- + testsuite/tests/stranal/should_run/T13380d.stderr
- + testsuite/tests/stranal/should_run/T13380e.hs
- + testsuite/tests/stranal/should_run/T13380e.stderr
- testsuite/tests/stranal/should_run/all.T
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/893a9737fcda41bbb3b19a2517559008da6fb9a3
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/893a9737fcda41bbb3b19a2517559008da6fb9a3
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20200429/e85d8e89/attachment.html>
More information about the ghc-commits
mailing list