<html><head></head><body>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.<br><br>Frankly, I wouldn't worry too much about this if it's nontrivial to fix. <br><br>Cheers, <br><br> - Ben <br><br><div class="gmail_quote">On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan" <omeragacan@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi Simon,<br><br>Currently CmmParse only generates CmmLabels for procs, and those are considered<br>non-CAFFY by hasCAF (and thus CmmBuildInfoTables).<br><br>As a result if I have two procs in a .cmm file:<br><br>- p1, refers to a CAF in base<br>- p2, refers to p1<br><br>I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we<br>don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be<br>considered CAFFY by hasCAF.<br><br>So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm<br>will never build SRTs for procs in .cmm files.<br><br>Is this intentional? I'd expect this to be possible, because there's nothing<br>preventing me from referring to a CAFFY definition in a library (e.g. base) in a<br>.cmm file, but doing this would be a bug in runtime.<br><br>Thanks,<br><br>Ömer<hr>ghc-devs mailing list<br>ghc-devs@haskell.org<br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br></pre></blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>