The curious case of #367: Infinite loops can hang Concurrent Haskell

[Moritz Angermann]

Hi Simon,

sure, I could have been a bit clearer:

Code we currently generate is:
```
 _cCO:
        bl _cCO
```

or

```
 _czf:
        mov x17, x18
        bl _czf
```

and the question then becomes, do we want to investigate if we can
a) detect this is dead code
b) remove it in Cmm or higher, or flat out prevent it from being generated.
c) we don't care about producing this code, and hope the linker will
eliminate it.

Cheers,
  Moritz

On Mon, Aug 17, 2020 at 5:18 PM Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> Moritz
>
> I'm not getting this.
>
> |  So, my question then is this: are we fine with ghc generating this
> |  code? Or, if we are not, do we want to figure out if we can eliminate
> |  it?
>
> What exactly is "this code" and "it"?
>
> You could be asking
>
> * Should we switch off -fomit-yields by default?
> * Should we implement -fno-omit-yields in a cleverer way that generates less code?
>
> Or you could be asking something else again.
>
> Your deadlock-detection patch (which is presumably not in GHC) is very special-case: it detects some infinite loops, but only some.   I'm not sure what role it plays in your thinking.
>
> Simon
>
>
> |  -----Original Message-----
> |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz
> |  Angermann
> |  Sent: 17 August 2020 09:40
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  Subject: The curious case of #367: Infinite loops can hang Concurrent
> |  Haskell
> |
> |  Hi there!
> |
> |  While working on a NCG, I eventually came across #367[0], which make GHC
> |  produce
> |  code that looks similar to this:
> |
> |  ```
> |  label:
> |    [non-branch-instructions]*
> |    brach-instruction label
> |  ```
> |
> |  so essentially an uninterruptible loop. The solution for GHC to
> |  produce code that
> |  can be interrupted is to pass -fno-omit-yields.
> |
> |  So far so good. Out of curiosity, I did add a small piece of code to
> |  detect this to my NCG
> |  to complain if code like the above was generated[1].
> |
> |  Three weeks ago, I kind of maneuvered myself into a memory blow up
> |  corner, and then
> |  life happened, but this weekend I managed to find some time to revert
> |  some memory
> |  blow up and continue working on the NCG.  Turns out I can build a
> |  stage2 "quick" flavour
> |  of the NCG without dynamic support just fine.  I never saw the dead
> |  lock detection code fire.
> |
> |  Now I did leave the test suite running yesterday night, and when
> |  looking through the
> |  test suite results, there were quite a few failure. Curiously a lot of
> |  them were due to
> |  ghc missing dynamic support (doh!).  But also quite a few that failed
> |  due to the deadlock
> |  detection.
> |
> |  T12485, hs_try_putmvar003, ds-wildcard, ds001, read029, T2817, tc011,
> |  tc021, T4524
> |
> |  So, my question then is this: are we fine with ghc generating this
> |  code? Or, if we are not, do we want to figure out if we can eliminate
> |  it? The issue 367 goes into quite a bit of detail why this is tricky
> |  to handle generally.
> |
> |  Or should we add -fno-omit-yields to the test-cases? The ultimate
> |  option is to just turn of the
> |  detection, and I'm fine with doing so. However I'd rather ask if
> |  anyone sees value in detecting
> |  this or not.
> |
> |  Cheers,
> |   Moritz
> |
> |  --
> |  [0]:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> |  askell.org%2Fghc%2Fghc%2F-
> |  %2Fissues%2F367&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e64
> |  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504
> |  423501799&sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D&amp
> |  ;reserved=0
> |  [1]:
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h
> |  askell.org%2Fghc%2Fghc%2F-
> |  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2FCmmT
> |  oAsm%2FAArch64%2FPpr.hs%23L134-
> |  159&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d84
> |  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&am
> |  p;sdata=RMXio8BI9tSjWnKK4HSXA3s%2BXNNM7ntk2ftQjmRJxzE%3D&reserved=0
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> |  ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c16608d8
> |  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637332504423501799&a
> |  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&reserved=0