While it's true that in principle one could imagine a case where you would want a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today. Consequently it wouldn't surprise me if this was broken.
Frankly, I wouldn't worry too much about this if it's nontrivial to fix.
Cheers,
- Ben
On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan"
Hi Simon,
Currently CmmParse only generates CmmLabels for procs, and those are considered non-CAFFY by hasCAF (and thus CmmBuildInfoTables).
As a result if I have two procs in a .cmm file:
- p1, refers to a CAF in base - p2, refers to p1
I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be considered CAFFY by hasCAF.
So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm will never build SRTs for procs in .cmm files.
Is this intentional? I'd expect this to be possible, because there's nothing preventing me from referring to a CAFFY definition in a library (e.g. base) in a .cmm file, but doing this would be a bug in runtime.
Thanks,
Ömer _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.