The problem occurs earlier in the pipeline than that. The generated C doesn't have the proper branching present in the original Haskell.

On 3/8/21 7:25 PM, Carter Schonwald wrote:
Isn’t the unregisterized backend a c compiler? You should check what gcc and clang or whoever we use handles those issues

On Mon, Mar 8, 2021 at 6:56 PM John Ericson <john.ericson@obsidian.systems> wrote:

    Hi everyone,

    https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717
    <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717> fails some
    numerical boundary checking tests with the unregisterized backend. In
    particular, `minBound / (-1)` and `pred minBound` are *not*
    diverging as
    expected. This stumped me a few days ago, and no new ideas have
    struct
    me since. I would very much appreciate some help.

    This does seem like something that is very likely to be
    backend-dependent, as different instructions/arches handle such edge
    cases in different ways. What makes this so peculiar, however, is
    that
    the boundary condition checking/branching is done *in regular
    Haskell*.
    I'm thus quite baffled as to what could be going wrong.

    If anyone wants to dive in, see my last comment
    https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_329840
    <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_329840>,

    which has a minimization to declutter the code without doing enough
    constant folding that the problem is avoided entirely. (I went with a
    compilation unit trick, but in hindsight NOINLINE should also work
    and
    be simpler.)

    Finally, let my provide some context for why I am hoping to get this
    merged soon. To be clear, !4492 was the main MR relating to the
    numerics
    primops critical to get in for 9.2 and it thankfully already
    landed. But
    landing this MR too would be nice: It shrinks the intermediate
    representations of numerical code probably smaller than it was
    originally, whereas now it is perhaps larger than it was before
    due to
    more size<->native conversions. Also, I think this MR will help get
    !3658 over the finish line, which, while again not as critical for
    9.2
    as !4492 was, would be awfully nice to do to fully realize the new
    simplicity of the plan set forth in
    https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics
    <https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics>.

    Thanks,

    John

    N.B. I just rebased and repushed the MR, so CI might be still
    running or
    failing due to something else, but based on local testing this is
    still
    the an issue. https://gitlab.haskell.org/ghc/ghc/-/pipelines/31002
    <https://gitlab.haskell.org/ghc/ghc/-/pipelines/31002> is an
    earlier pipeline run that one can look at until CI finishes again.

    _______________________________________________
    ghc-devs mailing list
    ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
    http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
    <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to