On 02/08/2013 09:15 AM, Florian Weimer wrote:
On 01/24/2013 08:55 PM, Diego Novillo wrote:
I do see, however, a few areas where Clang/LLVM have gone that I do
not think GCC is currently thinking of entering: "toolability" (for
the lack of a better term). Clang's design follows a different path
than g++. It's not just a code generating parser, it is a pure parser
that also generates code. The difference makes it suitable for any
kind of tool that needs to understand C++: static analyzers, code
re-formatters, syntax highlighters, and other similar tools.
Additionally, it is designed as a library, so it can be embedded into
applications.
I'm not quite sure that this clean split is possible, even after making
amends for template instantiation. It's great for syntax-driven tools,
but once you move beyond that, you tend to ignore stuff like destructors
(or the cleanup attribute), life-times of temporaries etc., things which
are just not visible in an AST. You have to reimplement many program
analysis algorithms typically part of compiler optimizers, after
lowering the AST to a less elaborate intermediate representation (a step
which requires a fair amount of knowledge about the language in question).
There's always going to be some things that are best done with the raw
ASTs and others which are best done when we've got a lowered IL, CFG,
SSA graph, etc.
The big question is how well can you go from the output of clang into a
lower level IR where you can do in depth analysis and how much you allow
optimizers to perturb the results of the analysis. One could argue that
clang -> gimple would be a useful translator to allow the nice things
from the clang front-end, but also still allow the more in-depth
analysis done by our tree-ssa code.
Jeff
