================
@@ -27,6 +27,8 @@ std::unique_ptr<Pass> createHoistAllocasPass();
 std::unique_ptr<Pass> createLoweringPreparePass();
 std::unique_ptr<Pass> createLoweringPreparePass(clang::ASTContext *astCtx);
 std::unique_ptr<Pass> createGotoSolverPass();
+std::unique_ptr<Pass> createIdiomRecognizerPass();
+std::unique_ptr<Pass> createIdiomRecognizerPass(clang::ASTContext *astCtx);
----------------
bcardosolopes wrote:

The pass creation requires a `clang::ASTContext *astCtx` in order to 
communicate to users "hey, AST is needed here", we need a better way to do 
that, this was the work around in the incubator for such tagging. If this 
wasn't added, someone would think it'd be possible to write standalone tests 
using cir-opt/mlir-opt (more on that below).

> I looked at the incubator, and it doesn't appear to be using astCtx anywhere 
> other than saving it and asserting that it isn't null

Right (because it's just tagging, like mentioned above). Note that the pass 
does use queries to AST interfaces (e.g. isStdFunctionCall) and will use more 
in the future (see TODO in `isIteratorLikeType`).

> I believe we need to be able to run the pass without an AST context in order 
> to run it from cir-opt/mlir-opt

I don't think this is feasible ATM anyways. It's a non-goal to replicate all 
the AST into CIR (even though we want to raise on a selective basis). Using the 
AST allows faster prototyping and development of analysis and optimizations, 
without necessarily requiring raising, this has been one of the lessons learned 
from Swift.

We discussed this before; in order to support standalone tools like cir-opt we 
need to serialize the AST alongside the CIR file, and teach the tools to 
serialize/deserialize using already existing clang functionality. No one has 
stepped up to work on this yet.

One middle ground would be to make AST requirement optional such that the pass 
could work on a "best effort" recognition mode, skipping things that would 
otherwise require AST availability. The downside here is how to tell standalone 
tools why they are not getting what they expect.

https://github.com/llvm/llvm-project/pull/172486
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to