Re: 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 
 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


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

Re: Requesting help with unregisterized backend failure of !4717

[Carter Schonwald]

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 
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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Requesting help with unregisterized backend failure of !4717

[John Ericson]

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