<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 21, 2011, at 4:25 PM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">On Wed, Dec 21, 2011 at 3:51 PM, Ted Kremenek<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">Thanks John. I discovered some of the issues by looking at the generated IR; looking at CodeGen was my next planned step.<br></blockquote><div><br></div><div>This again makes me wish that we could begin working to actually implement CodeGen in terms of the CFG so that we both share some of the burden of implementing this logic, and more importantly can share in the testing of the logic. Anyways, that's still more invasive, so I just wanted to keep people thinking about it...</div><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; "><br>Cheers,<br>Ted<br><div class="HOEnZb"><br class="Apple-interchange-newline"></div></blockquote></span></blockquote></div><br><div>I think there is strong merit in doing this, and this has been discussed (offline) before.</div><div><br></div><div>Historically, the design choice of having CodeGen and the CFG be independent came when the CFG was being used exclusively for the static analyzer. Thus the CFG wasn't needed for the compiler at all, and thus it was slightly faster to not build the CFG.</div><div><br></div><div>Only later, when we had a bunch of compiler warnings based on top of the CFG, did that base assumption here change. We still don't build CFGs for static inline functions in system headers (because we would suppress those warnings), but we don't do codegen for those functions all the time either.</div><div><br></div><div>Changing CodeGen to be built on top of the CFG would provide some great self-consistency, but there are tradeoffs (potential performance related) with the approach, not to mention that this would be a significant engineering project. If someone wants to play around with doing an alternate implementation of CodeGen based on the CFG, I would support such an effort. We can only evaluate that approach if we actually do it.</div></body></html>