[cfe-dev] LLVM Dev meeting: Slides & Minutes from the Static Analyzer BoF

[Chris Lattner via cfe-dev]

> On Nov 2, 2015, at 4:32 PM, Anna Zaks via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> - Alternate IRGen for better CFG: Correctly modeling temporary objects is hard. We can see that CodeGen is jumping through a lot of hoops to make it work. We would need to repeat a lot of it in the analyzer. This is a problem not only with temporaries but in general due to the analyzer being fed clang ASTs. C++ exceptions not being properly handled by the CFG is another example. We always have to play catch-up with the compiler and add support for new language features. This is hard and takes up a lot of time. Swift went with SIL (Swift Intermediate Language) specifically to solve a very similar problem - allowing analysis and CodeGen to reuse the same IR. (See the SIL talk that Chris L. and Joe G. gave earlier in the day.) This solution would be a lot of work and require a rewrite of both the analyzer and CodeGen. Should we perform static analysis on enriched LLVM IR instead?

I’m sorry I missed this part of the discussion, but IMO, but the right answer is to build a “CIL” analog to “SIL”.  The problems with the existing Clang CFG are that:

a) it is not tested as part of IRGen, so it falls out of date.
b) it is not a proper IR, which can be serialized/deserialized etc.  This makes it very difficult to write tests for.
c) its “operations” or “instructions" are defined as AST nodes, so its “CILGen” stage doesn’t allow any lowering of operations.

If you instead introducing a new IR that uses the Clang type system but somewhat lowered operations, you could significantly simplify CodeGen (which, of course, should also be named IRGen).  CILGen would handle things like lowering of temporaries, ctor/dtor invocations, control flow operations, etc.  The resulting “CIL” code would provide the natural representation for flow-sensitive clang warnings as well as the path sensitive ones that the static analyzer produces.  By having a first-class IR, we could entertain ideas of linking these files together to do interprocedural static analyses.  

That said, the huge and major disadvantage of this direction is that it is a tremendous amount of work to do...

-Chris

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