[cfe-dev] Implementing front-end of a user-directed optimization

[Richard Smith via cfe-dev]

On Wed, 10 Jun 2020, 13:31 Michael Kruse via cfe-dev, <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> I am working on user-directed optimizations/transformations as well. A
> lot depends on where you want to apply the optimization: On the (1)
> AST-level in the frontend, during (2) IR-gen in the front-end or on
> the (3) IR-level in the mid/back-end, (4) as a source-to-source
> transformation.
>
> For (1), there a TreeTransform to transform an AST subtree into
> another one. This an approach I took for
> https://reviews.llvm.org/D76342


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.)

The approach (2) is used by clang's OpenMP implementation.
>
> For (3), one emits metadata into the LLVM-IR.
> https://reviews.llvm.org/D70572 uses this approach. Instead of
> introducing a new AST node kind, one can also use the AttributedStmt
> kind and introduce an attribute on statements. This is the approach by
> https://github.com/SOLLVE/llvm-project/tree/pragma-clang-loop and
> generally used to implement the current `#pragma clang loop`
> annotations.
>
> With (4), one would use clang to only parse the source into an AST and
> use a Rewriter class to emit a new source code.
>
>
> Since there is no interface for clang library users to insert custom
> AST nodes or attributes, this leaves two choices:
>
> A source-to-source transformation (4):
>  * Ask clang to parse some source code and return the AST
>  * Register a pragma handler to callback when your custom pragma is seen.
>  * In the pragma handler insert the annotate attribute (which just
> takes a string)
>  * When encountering the annotation during the AST walk, your tool can
> react.
>
> Or process the annotation attribute which is emitted as a
> `llvm.*.annotation` builtin in the IR (1):
>  * Register the pragma handler as before
>  * Register a pass plugin in LLVM which looks for the annotation builtins.
>

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.

Michael
>
>
>
>
>
>
> Am Mi., 10. Juni 2020 um 14:45 Uhr schrieb Probir Roy via cfe-dev
> <cfe-dev at lists.llvm.org>:
> >
> > Hi cfe-dev,
> >
> > I am implementing a user-guided optimization (xTool).
> > Programmers will provide pragma directives to guide the backend. Since
> > I am new to LLVM and clang, I am having a hard time figuring out how
> > to implement it. Here are the steps I am considering for the frontend:
> >
> > User will provide directives as:
> >
> > #pragma xTool someClause
> > {
> >      Compound statements
> > }
> >
> > I want to implement directives handling as a "clang plug-in". I am
> > thinking to create AST node classes for xTool directive inheriting
> > Stmt class from the plug-in. Is it possible with current clang? If it
> > is possible I can access the compound statements enclosed in {} with
> > "CapturedStmt". Or should I consider to "annotate" the stmt node
> > instead of creating a new class?
> >
> > Any feedback on how to implement this on the clang frontend would be
> > really helpful. So far I have looked into few codes of the OpenMP
> > directive implementation.
> >
> > --
> > Probir
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200611/91072269/attachment.html>