<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 10 Jun 2020, 13:31 Michael Kruse via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am working on user-directed optimizations/transformations as well. A<br>
lot depends on where you want to apply the optimization: On the (1)<br>
AST-level in the frontend, during (2) IR-gen in the front-end or on<br>
the (3) IR-level in the mid/back-end, (4) as a source-to-source<br>
transformation.<br>
<br>
For (1), there a TreeTransform to transform an AST subtree into<br>
another one. This an approach I took for<br>
<a href="https://reviews.llvm.org/D76342" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D76342</a></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This approach is generally not in line with clang's design philosophy and should be avoided where feasible. (If you need to do semantic analysis on the result of the transformation, then it's typically not feasible to avoid it; in such cases the best we can do is to retain both the original source form and the (minimally) desugared form. But that should typically not be necessary for an optimization.)</div><div dir="auto"><br></div><div dir="auto"></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The approach (2) is used by clang's OpenMP implementation.<br>
<br>
For (3), one emits metadata into the LLVM-IR.<br>
<a href="https://reviews.llvm.org/D70572" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D70572</a> uses this approach. Instead of<br>
introducing a new AST node kind, one can also use the AttributedStmt<br>
kind and introduce an attribute on statements. This is the approach by<br>
<a href="https://github.com/SOLLVE/llvm-project/tree/pragma-clang-loop" rel="noreferrer noreferrer" target="_blank">https://github.com/SOLLVE/llvm-project/tree/pragma-clang-loop</a> and<br>
generally used to implement the current `#pragma clang loop`<br>
annotations.<br>
<br>
With (4), one would use clang to only parse the source into an AST and<br>
use a Rewriter class to emit a new source code.<br>
<br>
<br>
Since there is no interface for clang library users to insert custom<br>
AST nodes or attributes, this leaves two choices:<br>
<br>
A source-to-source transformation (4):<br>
* Ask clang to parse some source code and return the AST<br>
* Register a pragma handler to callback when your custom pragma is seen.<br>
* In the pragma handler insert the annotate attribute (which just<br>
takes a string)<br>
* When encountering the annotation during the AST walk, your tool can react.<br>
<br>
Or process the annotation attribute which is emitted as a<br>
`llvm.*.annotation` builtin in the IR (1):<br>
* Register the pragma handler as before<br>
* Register a pass plugin in LLVM which looks for the annotation builtins.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It would also be possible to implement the transform in a fork of clang rather than using clang as a library, or to propose patches to expand the library interface to support the desired extensibility in general. Each option has a different set of tradeoffs.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Michael<br>
<br>
<br>
<br>
<br>
<br>
<br>
Am Mi., 10. Juni 2020 um 14:45 Uhr schrieb Probir Roy via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>>:<br>
><br>
> Hi cfe-dev,<br>
><br>
> I am implementing a user-guided optimization (xTool).<br>
> Programmers will provide pragma directives to guide the backend. Since<br>
> I am new to LLVM and clang, I am having a hard time figuring out how<br>
> to implement it. Here are the steps I am considering for the frontend:<br>
><br>
> User will provide directives as:<br>
><br>
> #pragma xTool someClause<br>
> {<br>
> Compound statements<br>
> }<br>
><br>
> I want to implement directives handling as a "clang plug-in". I am<br>
> thinking to create AST node classes for xTool directive inheriting<br>
> Stmt class from the plug-in. Is it possible with current clang? If it<br>
> is possible I can access the compound statements enclosed in {} with<br>
> "CapturedStmt". Or should I consider to "annotate" the stmt node<br>
> instead of creating a new class?<br>
><br>
> Any feedback on how to implement this on the clang frontend would be<br>
> really helpful. So far I have looked into few codes of the OpenMP<br>
> directive implementation.<br>
><br>
> --<br>
> Probir<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div>