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-boun...@haskell.org> On Behalf Of Moritz | Angermann | Sent: 17 August 2020 09:40 | To: ghc-devs <ghc-devs@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& | ;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@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs