RE: StgCase - are LiveVars and SRT fields going to be used?
Those fields are dead, now that the Cmm pass deals with it. We left it in while making the transition, but they can go now. Go ahead! (Lots of code should disappear along with them!) Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ömer Sinan | Agacan | Sent: 01 February 2016 22:06 | To: ghc-devs | Subject: StgCase - are LiveVars and SRT fields going to be used? | | Hi all, | | This is how case expression in STG currently defined: | | | | StgCase | (GenStgExpr bndr occ) | (GenStgLiveVars occ) | (GenStgLiveVars occ) | bndr | SRT | AltType | [GenStgAlt bndr occ] | | | The GenStgLiveVars and SRT fields are never used anywhere in the compiler | (except the printer). So the question is, I'm assuming those were used at | some | point, but are they going to be used in the future? Or can I just delete | those? | | As a proof of concept, I just compiled GHC using this: | | | | StgCase | (GenStgExpr bndr occ) | bndr | AltType | [GenStgAlt bndr occ] | | | Normally this is not a big deal, but I'm doing lots of STG-to-STG | transformations nowadays, and I have to keep those field updated which is | annoying as those are never going to be used (I can't even know if I'm doing | it | right), or leave those `undefined` which is not a good practice. | ___ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c12ca56c8fc514f477f7f08 | d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupNbUJ9OGL9cmbP%2f | PAs2JSdxqlxk%2bGbXuYTHFbzg%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: StgCase - are LiveVars and SRT fields going to be used?
https://phabricator.haskell.org/D1880 2016-02-01 18:04 GMT-05:00 Simon Peyton Jones : > Those fields are dead, now that the Cmm pass deals with it. We left it in > while making the transition, but they can go now. Go ahead! > > (Lots of code should disappear along with them!) > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ömer Sinan > | Agacan > | Sent: 01 February 2016 22:06 > | To: ghc-devs > | Subject: StgCase - are LiveVars and SRT fields going to be used? > | > | Hi all, > | > | This is how case expression in STG currently defined: > | > | > | | StgCase > | (GenStgExpr bndr occ) > | (GenStgLiveVars occ) > | (GenStgLiveVars occ) > | bndr > | SRT > | AltType > | [GenStgAlt bndr occ] > | > | > | The GenStgLiveVars and SRT fields are never used anywhere in the compiler > | (except the printer). So the question is, I'm assuming those were used at > | some > | point, but are they going to be used in the future? Or can I just delete > | those? > | > | As a proof of concept, I just compiled GHC using this: > | > | > | | StgCase > | (GenStgExpr bndr occ) > | bndr > | AltType > | [GenStgAlt bndr occ] > | > | > | Normally this is not a big deal, but I'm doing lots of STG-to-STG > | transformations nowadays, and I have to keep those field updated which is > | annoying as those are never going to be used (I can't even know if I'm doing > | it > | right), or leave those `undefined` which is not a good practice. > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. > | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | > devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c12ca56c8fc514f477f7f08 > | > d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupNbUJ9OGL9cmbP%2f > | PAs2JSdxqlxk%2bGbXuYTHFbzg%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: StgCase - are LiveVars and SRT fields going to be used?
Simon, I broke the debug build with that commit. I actually validated locally before committing, but apparently the default validate settings doesn't define DEBUG, so the new assertion implementation was not tested. (Why validate doesn't define DEBUG by default???) The fastest way to reproduce the bug is to use these validate settings: DYNAMIC_GHC_PROGRAMS = NO GhcLibWays = v GhcStage1HcOpts += -DDEBUG I did some debugging. Here's an example definition that causes the assertion failure: unpackCString# unpackCString# [InlPrag=NOINLINE] :: Addr# -> [Char] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] = \r [addr_seX] let { unpack_seY [Occ=LoopBreaker] :: Int# -> [Char] [LclId, Arity=1, Str=DmdType , Unf=OtherCon []] = sat-only \r [nh_seZ] case indexCharOffAddr# [addr_seX nh_seZ] of ch_sf0 { __DEFAULT -> let { sat_sf3 [Occ=Once] :: [Char] [LclId, Str=DmdType] = \u [] case +# [nh_seZ 1#] of sat_sf2 { __DEFAULT -> unpack_seY sat_sf2; }; } in let { sat_sf1 [Occ=Once] :: Char [LclId, Str=DmdType] = NO_CCS C#! [ch_sf0]; } in : [sat_sf1 sat_sf3]; '\NUL'# -> [] []; }; } in unpack_seY 0#; Here the IdInfo says this doesn't have CAF refs, but `sat_sf3` is updatable, so in our assertion we say that this has a CAF. In the implementation I basically followed your description: " - If the binding is an updatable thunk, it has CAF refs. - Otherwise it has CAF reffs iff any of its free Ids (including imported ones) has mayHaveCafRefs in its IdInfo. Actually you can probably ignore the "free" part and just check if any Id has mayHaveCafRefs set. " The first case is why we say "yes" to stgBindHasCafRefs. But I don't quite understand why we say every updatable thunk has CAFs. I think this is only the case with top-level updatable thunks, right? If no, then maybe the problem is not with the assertion but rather with the CorePrep step that sets IdInfos? Any ideas? Thanks.. 2016-02-01 20:19 GMT-05:00 Ömer Sinan Ağacan : > https://phabricator.haskell.org/D1880 > > 2016-02-01 18:04 GMT-05:00 Simon Peyton Jones : >> Those fields are dead, now that the Cmm pass deals with it. We left it in >> while making the transition, but they can go now. Go ahead! >> >> (Lots of code should disappear along with them!) >> >> Simon >> >> | -Original Message- >> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ömer >> Sinan >> | Agacan >> | Sent: 01 February 2016 22:06 >> | To: ghc-devs >> | Subject: StgCase - are LiveVars and SRT fields going to be used? >> | >> | Hi all, >> | >> | This is how case expression in STG currently defined: >> | >> | >> | | StgCase >> | (GenStgExpr bndr occ) >> | (GenStgLiveVars occ) >> | (GenStgLiveVars occ) >> | bndr >> | SRT >> | AltType >> | [GenStgAlt bndr occ] >> | >> | >> | The GenStgLiveVars and SRT fields are never used anywhere in the compiler >> | (except the printer). So the question is, I'm assuming those were used at >> | some >> | point, but are they going to be used in the future? Or can I just delete >> | those? >> | >> | As a proof of concept, I just compiled GHC using this: >> | >> | >> | | StgCase >> | (GenStgExpr bndr occ) >> | bndr >> | AltType >> | [GenStgAlt bndr occ] >> | >> | >> | Normally this is not a big deal, but I'm doing lots of STG-to-STG >> | transformations nowadays, and I have to keep those field updated which is >> | annoying as those are never going to be used (I can't even know if I'm >> doing >> | it >> | right), or leave those `undefined` which is not a good practice. >> | ___ >> | ghc-devs mailing list >> | ghc-devs@haskell.org >> | >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. >> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >> | >> devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c12ca56c8fc514f477f7f08 >> | >> d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupNbUJ9OGL9cmbP%2f >> | PAs2JSdxqlxk%2bGbXuYTHFbzg%3d ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: StgCase - are LiveVars and SRT fields going to be used?
I submitted https://phabricator.haskell.org/D1889 which hopefully fixes this properly. 2016-02-05 21:50 GMT-05:00 Ömer Sinan Ağacan : > Simon, I broke the debug build with that commit. I actually validated locally > before committing, but apparently the default validate settings doesn't define > DEBUG, so the new assertion implementation was not tested. (Why validate > doesn't define DEBUG by default???) > > The fastest way to reproduce the bug is to use these validate settings: > > DYNAMIC_GHC_PROGRAMS = NO > GhcLibWays = v > GhcStage1HcOpts += -DDEBUG > > I did some debugging. Here's an example definition that causes the assertion > failure: > > unpackCString# > unpackCString# [InlPrag=NOINLINE] :: Addr# -> [Char] > [GblId, >Arity=1, >Caf=NoCafRefs, >Str=DmdType , >Unf=OtherCon []] = > \r [addr_seX] > let { > unpack_seY [Occ=LoopBreaker] :: Int# -> [Char] > [LclId, Arity=1, Str=DmdType , Unf=OtherCon []] = > sat-only \r [nh_seZ] > case indexCharOffAddr# [addr_seX nh_seZ] of ch_sf0 { > __DEFAULT -> > let { > sat_sf3 [Occ=Once] :: [Char] > [LclId, Str=DmdType] = > \u [] > case +# [nh_seZ 1#] of sat_sf2 { > __DEFAULT -> unpack_seY sat_sf2; > }; } in > let { > sat_sf1 [Occ=Once] :: Char > [LclId, Str=DmdType] = > NO_CCS C#! [ch_sf0]; > } in : [sat_sf1 sat_sf3]; > '\NUL'# -> [] []; > }; > } in unpack_seY 0#; > > Here the IdInfo says this doesn't have CAF refs, but `sat_sf3` is updatable, > so > in our assertion we say that this has a CAF. In the implementation I basically > followed your description: > > " > - If the binding is an updatable thunk, it has CAF refs. > > - Otherwise it has CAF reffs iff any of its free Ids (including imported ones) > has mayHaveCafRefs in its IdInfo. Actually you can probably ignore the > "free" > part and just check if any Id has mayHaveCafRefs set. > " > > The first case is why we say "yes" to stgBindHasCafRefs. But I don't quite > understand why we say every updatable thunk has CAFs. I think this is only the > case with top-level updatable thunks, right? If no, then maybe the problem is > not with the assertion but rather with the CorePrep step that sets IdInfos? > Any > ideas? > > Thanks.. > > 2016-02-01 20:19 GMT-05:00 Ömer Sinan Ağacan : >> https://phabricator.haskell.org/D1880 >> >> 2016-02-01 18:04 GMT-05:00 Simon Peyton Jones : >>> Those fields are dead, now that the Cmm pass deals with it. We left it in >>> while making the transition, but they can go now. Go ahead! >>> >>> (Lots of code should disappear along with them!) >>> >>> Simon >>> >>> | -Original Message- >>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ömer >>> Sinan >>> | Agacan >>> | Sent: 01 February 2016 22:06 >>> | To: ghc-devs >>> | Subject: StgCase - are LiveVars and SRT fields going to be used? >>> | >>> | Hi all, >>> | >>> | This is how case expression in STG currently defined: >>> | >>> | >>> | | StgCase >>> | (GenStgExpr bndr occ) >>> | (GenStgLiveVars occ) >>> | (GenStgLiveVars occ) >>> | bndr >>> | SRT >>> | AltType >>> | [GenStgAlt bndr occ] >>> | >>> | >>> | The GenStgLiveVars and SRT fields are never used anywhere in the compiler >>> | (except the printer). So the question is, I'm assuming those were used at >>> | some >>> | point, but are they going to be used in the future? Or can I just delete >>> | those? >>> | >>> | As a proof of concept, I just compiled GHC using this: >>> | >>> | >>> | | StgCase >>> | (GenStgExpr bndr occ) >>> | bndr >>> | AltType >>> | [GenStgAlt bndr occ] >>> | >>> | >>> | Normally this is not a big deal, but I'm doing lots of STG-to-STG >>> | transformations nowadays, and I have to keep those field updated which is >>> | annoying as those are never going to be used (I can't even know if I'm >>> doing >>> | it >>> | right), or leave those `undefined` which is not a good practice. >>> | ___ >>> | ghc-devs mailing list >>> | ghc-devs@haskell.org >>> | >>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell. >>> | org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >>> | >>> devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c12ca56c8fc514f477f7f08 >>> | >>> d32b53f4bc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LPiupN