On Thu, Apr 19, 2012 at 10:20 PM, Diego Novillo <dnovi...@google.com> wrote: > On 4/19/12 4:14 PM, Andrew Pinski wrote: > >> How do you know it is a major effort? Has any issues related to >> changing Tuple/front-ends AST been raised to the mailing list and >> asked for help on how to implement these changes? > > > The kind of analysis that Annotalysis needs cannot be catered by GIMPLE, the > same way that LLVM's bitcode could not cater to it. Both representations > are geared towards code transformations, not source code analysis. It's not > an implementation issue, but a design one. It simply does not make sense > for GIMPLE or LLVM's bitcode to try to be a source code analysis framework. > > Annotalysis needs a high-fidelity representation of the original source > code. Today, that high-fidelity representation is provided exclusively by > Clang. > > Additionally, we are already supporting Clang as a front end to provide > syntax and semantic analysis. Given that Clang provides a much more > flexible framework for static analysis, the decision was a relatively simple > one. > > This is not to say that Clang provides everything needed by Annotalysis. > There is some need to use dataflow information which needs to be > incorporated in Clang. However, a large fraction of the support required > was already available in Clang.
Our high-level AST is language specific. In case of C++ its GENERIC plus some C++ specific tree codes. There is no framework for building a CFG on top of that (not sure if you need that), but the cgraph is built over that representation. Of course non-optimizing ASTs will limit static analysis to TU scope, even with clang? Or does clang support a "LTO" source AST? Richard. > > Diego.