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

[Manuel Klimek via cfe-dev]

On Tue, Nov 3, 2015 at 9:46 AM David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:

> On 3 Nov 2015, at 17:26, Manuel Klimek via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
> >
> > What are your arguments against implementing a type system on top of
> llvm IR (that lives on a similar level as debug info) that is not language
> specific per se, but allows frontends to model their language semantics and
> have pointers back to their AST? Do you believe such a type system would
> inherently be coupled to language semantics, and thus not possible to build
> in a generic enough (and still useful) way? Or are there other problems?
>
> I don’t think that there’s anything wrong with the *idea* of doing this,
> but the implementation is very hard.  The CIR (not going to call it CIL)
> would, intrinsically, only support transforms that supported the generic C
> semantics and would know enough to update all C-relevant data.  When you
> lower to LLVM IR, even if you’re tagging everything with an AST node, you’d
> need all passes to understand how to update this information.


I'd like to understand why all passes would need to keep the information.
Some most certainly would (because static analysis will benefit from some
passes), but I'd expect many passes to lose the information without it
being problematic.


> Given how badly most of them (even SROA / mem2reg, without which most
> analyses would be largely useless) do with debug info, which is at a far
> lower fidelity than this sort of thing would need, it’s very hard for me to
> imagine getting it right for a C AST, let alone a C++AST.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151103/1506a1aa/attachment.html>