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

[Probir Roy via cfe-dev]

I will perform link-time optimization. At the front-end, I want to
generate a module summary in the IR guided by the user pragmas. At
link-time, I will perform a summary based whole program analysis.

For this should I consider approach (2): IR-gen in the front-end? If
that's the case, I will need to modify Clang to insert a new AST node
class, right? Where should I write the pass to generate the module
summary? Also, how to get the associated CapturedStmt? Code examples
would be very helpful.

-Probir


On Wed, Jun 10, 2020 at 4:31 PM Michael Kruse <llvm at meinersbur.de> 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
>
> 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.
>
>
> 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