[cfe-dev] Extra join points in CFG?

Chris Lattner clattner at apple.com
Wed Dec 21 20:10:21 PST 2011


On Dec 21, 2011, at 5:50 PM, Ted Kremenek wrote:

> 
> On Dec 21, 2011, at 4:25 PM, Chandler Carruth wrote:
> 
>> On Wed, Dec 21, 2011 at 3:51 PM, Ted Kremenek <kremenek at apple.com> wrote:
>> Thanks John.  I discovered some of the issues by looking at the generated IR; looking at CodeGen was my next planned step.
>> 
>> 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...
>>  
>> 
>> Cheers,
>> Ted
>> 
> 
> I think there is strong merit in doing this, and this has been discussed (offline) before.
> 
> 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.
> 
> 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.

>From my perspective, building codegen on top of the CFG is "clearly" the right thing to do from a pure engineering standpoint.  That way all the logic for dealing with this sort of thing would be in one place, and it is frankly much easier to test IRGen than it is to test the analyzer.

However, from a pragmatic/realistic standpoint, doing this would "probably" be a significant slowdown for compile times, particularly exception handling situations.  However, since the early decision was made, we've gone to building the CFG for each function *anyway* for flow sensitive warnings.  Perhaps a new implementation may not be as costly and might be worth it.

It is clearly a big project though.  The first necessary step is to improve the CFG to handle everything that codegen does.  Fortunately, that is a really valuable and worthwhile project regardless of whether codegen switches.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111221/cc4add4b/attachment.html>


More information about the cfe-dev mailing list