Requesting help with unregisterized backend failure of !4717
Hi everyone, 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, 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. 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 is an earlier pipeline run that one can look at until CI finishes again.
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 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, 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.
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 is an earlier pipeline run that one can look at until CI finishes again.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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>
participants (2)
-
Carter Schonwald -
John Ericson