• Ben Gamari's avatar
    Fix treatment of -0.0 · eb975d2e
    Ben Gamari authored
    Here we fix a few mis-optimizations that could occur in code with
    floating point comparisons with -0.0. These issues arose from our
    insistence on rewriting equalities into case analyses and the
    simplifier's ignorance of floating-point semantics.
    For instance, in Trac #10215 (and the similar issue Trac #9238) we
    turned `ds == 0.0` into a case analysis,
    case ds of
        __DEFAULT -> ...
        0.0 -> ...
    Where the second alternative matches where `ds` is +0.0 and *also* -0.0.
    However, the simplifier doesn't realize this and will introduce a local
    inlining of `ds = -- +0.0` as it believes this is the only
    value that matches this pattern.
    Instead of teaching the simplifier about floating-point semantics
    we simply prohibit case analysis on floating-point scrutinees and keep
    this logic in the comparison primops, where it belongs.
    We do several things here,
     - Add test cases from relevant tickets
     - Clean up a bit of documentation
     - Desugar literal matches against floats into applications of the
       appropriate equality primitive instead of case analysis
     - Add a CoreLint to ensure we don't pattern match on floats in Core
    Test Plan: validate with included testcases
    Reviewers: goldfire, simonpj, austin
    Subscribers: thomie
    Differential Revision: https://phabricator.haskell.org/D1061
    GHC Trac Issues: #10215, #9238
T9238.hs 538 Bytes