<div dir="auto">Isn’t the unregisterized backend a c compiler? You should check what gcc and clang or whoever we use handles those issues </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 8, 2021 at 6:56 PM John Ericson <john.ericson@obsidian.systems> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi everyone,<br>
<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717</a> fails some <br>
numerical boundary checking tests with the unregisterized backend. In <br>
particular, `minBound / (-1)` and `pred minBound` are *not* diverging as <br>
expected. This stumped me a few days ago, and no new ideas have struct <br>
me since. I would very much appreciate some help.<br>
<br>
This does seem like something that is very likely to be <br>
backend-dependent, as different instructions/arches handle such edge <br>
cases in different ways. What makes this so peculiar, however, is that <br>
the boundary condition checking/branching is done *in regular Haskell*. <br>
I'm thus quite baffled as to what could be going wrong.<br>
<br>
If anyone wants to dive in, see my last comment <br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_329840" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_329840</a>, <br>
which has a minimization to declutter the code without doing enough <br>
constant folding that the problem is avoided entirely. (I went with a <br>
compilation unit trick, but in hindsight NOINLINE should also work and <br>
be simpler.)<br>
<br>
Finally, let my provide some context for why I am hoping to get this <br>
merged soon. To be clear, !4492 was the main MR relating to the numerics <br>
primops critical to get in for 9.2 and it thankfully already landed. But <br>
landing this MR too would be nice: It shrinks the intermediate <br>
representations of numerical code probably smaller than it was <br>
originally, whereas now it is perhaps larger than it was before due to <br>
more size<->native conversions. Also, I think this MR will help get <br>
!3658 over the finish line, which, while again not as critical for 9.2 <br>
as !4492 was, would be awfully nice to do to fully realize the new <br>
simplicity of the plan set forth in <br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics</a>.<br>
<br>
Thanks,<br>
<br>
John<br>
<br>
N.B. I just rebased and repushed the MR, so CI might be still running or <br>
failing due to something else, but based on local testing this is still <br>
the an issue. <a href="https://gitlab.haskell.org/ghc/ghc/-/pipelines/31002" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/pipelines/31002</a> is an <br>
earlier pipeline run that one can look at until CI finishes again.<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>