| 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.angerm...@gmail.com> | Sent: 17 August 2020 10:30 | To: Simon Peyton Jones <simo...@microsoft.com> | Cc: ghc-devs <ghc-devs@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 | <simo...@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-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%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 | & | > | ;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@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
