[cfe-dev] extending ClangTool libASTUnit saving and loading

Manuel Klimek klimek at google.com
Wed Dec 17 02:10:42 PST 2014


On Tue Dec 16 2014 at 7:20:42 PM mobi phil <mobi at mobiphil.com> wrote:

>
>
>> So, why do you want to do that? What's your use case? :)
>>
>
> does your answer mean that it is impossible to tell clang to load the ast
> instead of re-parsing re-syntactic-analyzing the source?
> Well, could throw back the ball and ask, why being able to save ast at all?
>

Well, there are currently multiple use cases in clang: pch files
(precompiled headers), pcm files (modules), and I think arcmigrate uses
ASTUnit (but I don't know the details).


> I use at this moment clang infra mainly to understand clang itself. I gave
> the Sema.cpp as example as it is probably the hugest file (absolute size
> not counting included headers). Probably with headers included lot of
> compilation unit would be almost equally large. Anyway the point is that
> compilation takes lot of time. Trying to understand how much potential is
> in a workflow where one would generate only once the ast, and subsequent
> processes would reuse the AST as mentioned earlier (code generation, static
> analysis etc, refactoring experiments). Well, for applying different
> optmisation strategies, the LLVM intermediate could play similar role.
>

The problem is that when you store the AST for a full TU, it's *huge* (all
the transitive headers are in it) and I'm not sure why you would want to do
that.
If you think tools are too slow, then our proposed solution for that is
using C++ modules (which will also dump the AST, but in a much more nuanced
and smart fashion).

That's why the use case matters; if you're interested in processing speed,
the solution is modules (and the way it serializes the AST).
If your use case is something else, the answer might be something different
:)



>
> As you can see, do not pretend to have a specific use case, but I also
> have the opinion that even simple features would never be asked explicitly
> as the threshold is a bit high, but these features would be probably used
> once present.
>
> can you also eventually confirm that simple command line
> clang Sema.ast
> treats Sema.ast as pch and not as ast?
>
>
> thanks and best regards
> mobi phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141217/d17ee79e/attachment.html>


More information about the cfe-dev mailing list