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

[Daniel Grumberg via cfe-dev]

You should look into the existing ThinLTO infrastructure, it does what you describe here, but at the IR level directly. This should be enough to get you going https://clang.llvm.org/docs/ThinLTO.html <https://clang.llvm.org/docs/ThinLTO.html> http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html <http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html> for a high level description of how this works.

Best,
—Daniel

> On 11 Jun 2020, at 13:23, Probir Roy via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 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
> _______________________________________________
> 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/bd917e7a/attachment-0001.html>