[cfe-dev] about AST of clang
Ronan.Keryell at hpc-project.com
Thu May 3 14:27:38 PDT 2012
>>>>> On Sat, 21 Apr 2012 10:29:58 +0200, Manuel Klimek <klimek at google.com> said:
Manuel> As I said before, I might not understand what you're trying
Manuel> to do. That said, I think that changing the code is a
Manuel> superset of changing the AST, so I don't understand why it's
Manuel> harder to do certain things that way. It of course requires
Manuel> a very precise mapping of AST nodes to source code, which
Manuel> clang luckily enough has. It also requires that you still
Manuel> want to do C++ (if you don't, that would be a case where
Manuel> what I say clarly does not apply).
My argumentation is that if the Clang front-end is used more and more as
a generic source-to-source translator, at some point we will need some
features helping the programmers to do so.
For example, just think to generating code for some kind of
heterogeneous accelerators, for example GPU. You need to outline some
pieces of code to new functions and it is quite complicated to do it in
the general case at the source level. Even at the AST level with more
suitable abstractions it is already difficult, as we can see in other
source-to-source compilers (as with ROSE Compiler & PIPS I know)
Manuel> As for changes of internal representation getting in your
Manuel> way - how's that better when you directly work on the AST -
Manuel> on the contrary, I expect subtle changes to the invariants
Manuel> of the AST to make it much harder to still produce correct
Manuel> ASTs by shoving around AST nodes, instead of making textual
That is true. But for quite complex transformation work, I'm not sure
there is another way...
Manuel> And third, if you ever want the changes to go back to the
Manuel> programmer in code form, you suddenly need to care about
Manuel> formatting etc, and minimally disruptive changes to the
Of course, I assume in the "higher level" support that we need, we keep
information on all the formatting stuff. :-)
But anyway, it is an intractable issue per se (transformation on code
with a macro expansion, what is the very semantics of a comment
envisioned by the programmer at some position in the code...), but we can
provide some support for simple cases.
Manuel> I don't understand yet why you think the direct tree
Manuel> transformation is per se cleaner.
Because at some point of transformation complexity, it is cleaner to
invest in some common high-end source-to-source transformation support
and rely on it to develop all the complex tools, rather than trying to
do too complex stuff with string transformations.
But it is related to what we expect to do with the tool and it may not
apply to you. I understand it may not be the mainstream use for
Clang. :-) For some of our use cases (not using Clang), have a look to
par4all.org for example.
Ronan KERYELL |\/ Phone: +1 408 658 9453
Wild Systems / HPC Project |/)
5201 Great America Parkway, Suite 320 K Ronan.Keryell at wild-systems.com
Santa Clara, CA 95054 |\ skype:keryell
USA | \ http://wild-systems.com
More information about the cfe-dev