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

[Simon Peyton Jones]

|  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.

I'm still puzzled.  Why do you thing _cCO is dead?  What alternative code are you thinking we might generate?

S

|  -----Original Message-----
|  From: Moritz Angermann <moritz.angermann at gmail.com>
|  Sent: 17 August 2020 10:30
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: The curious case of #367: Infinite loops can hang
|  Concurrent Haskell
|  
|  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%2Fgitl
|  ab.h
|  > |  askell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fissues%2F367&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead06
|  2e64
|  > |
|  1e6c16608d842893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733
|  2504
|  > |
|  423501799&sdata=KKZYaNgl%2FliDXwfcEqWIosjRjDYt%2FDc9i1sBEfS22mQ%3D
|  &amp
|  > |  ;reserved=0
|  > |  [1]:
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.h
|  > |  askell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fblob%2F46fba2c91e1c4d23d46fa2d9b18dcd000c80363d%2Fcompiler%2FGHC%2F
|  CmmT
|  > |  oAsm%2FAArch64%2FPpr.hs%23L134-
|  > |
|  159&data=02%7C01%7Csimonpj%40microsoft.com%7C06a6ead062e641e6c1660
|  8d84
|  > |
|  2893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63733250442350179
|  9&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%7C06a6ead062e641e6c166
|  08d8
|  > |
|  42893959%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373325044235017
|  99&a
|  > |
|  mp;sdata=8W595qb3lWsqdAeGeFp0T26DsCXzA6ngrCQLKihCXkA%3D&reserved=0