Requesting help with unregisterized backend failure of !4717

[John Ericson]

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 at 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 at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210309/7c80cf19/attachment.html>