Add an CIR analysis-only pipeline that uses traditional codegen

[ChuanqiXu9]

This comes from https://discourse.llvm.org/t/rfc-upstreaming-clangir/76587/53

It may be helpful to have an analysis only pipeline so that users can try to use CIR actually without worrying the correctness and completeness of the CIR to LLVM IR part.

The pattern may look like:

Source -> Parser and Sema -> AST -----> CIR -----> analysis pass and transforming pass helper for analysis              
                               |
                               ------> CodeGen ------->  LLVM IR

So we can have multiple consumers for the parsed AST. One the traditional code gen part. The other one is the new introduced CIR part. We generate CIR from AST and we can perform analysis on the CIR. We can also perform some transformation passes on the CIR if these transformation passes are helpful to the analysis.

Is it possible to do so? If not, would we love to do? I think it will be pretty helpful to get more users for CIR.

[Lancern]

Hi Chuanqi. This should be a first-class use case of clangir. You can pass -emit-cir switch to clang_cc1 to emit CIR only and avoid the CIR -> MLIR/LLVMIR part. Along the way one may still run any analysis passes and CIR -> CIR transformation passes.

clangir already has a PoC implementation of a lifetime checker, which can be found at https://github.com/llvm/clangir/blob/main/clang/lib/CIR/Dialect/Transforms/LifetimeCheck.cpp (but for now it might be a bit out-of-date). One can run this analysis pass via:

clang++ -cc1 -fclangir -emit-cir -fclangir-lifetime-check -o output.cir input.cpp

I like your idea about an "analysis-only" pipeline. The problem with the above pipeline is that it still run some passes that are required for CIR -> MLIR/LLVMIR but are not required for an analysis-only pipeline (LoweringPrepare is a typical one).

[ChuanqiXu9]

Hi,

the interface looks like not the one I want.

What I want is:

clang++ input.cpp -fenable-cir-check -c -o input.o

That is, it is just normal compilation except we add some new analysis. If we can do this, it is much easier to enable CIR for real world users.

[bcardosolopes]

Hi @ChuanqiXu9, thanks for clarifying your question.

Right now, if you use -fclangir you're not going to get what you want, because it will enable CIR for codegen as well, as you probably noticed, hence this issue. I guess at some point we could have a -fclangir-analysis-only or something like that to do what you are asking for.

We don't have anything like that right now because none of our users have that usecase, and we avoid adding things that there are no uses for, but nothing prevents it being added at some point. It'd be useful for instance when running the lifetime checker without changing the existing codegen path.

To summarize: we have no plans or intention to change -fclangir meaning, but it would be totally fine to add something like a -fclangir-analysis-only (btw, it's a rather simple change to do that).

[ChuanqiXu9]

Hi @ChuanqiXu9, thanks for clarifying your question.

Right now, if you use -fclangir you're not going to get what you want, because it will enable CIR for codegen as well, as you probably noticed, hence this issue. I guess at some point we could have a -fclangir-analysis-only or something like that to do what you are asking for.

We don't have anything like that right now because none of our users have that usecase, and we avoid adding things that there are no uses for, but nothing prevents it being added at some point. It'd be useful for instance when running the lifetime checker without changing the existing codegen path.

To summarize: we have no plans or intention to change -fclangir meaning, but it would be totally fine to add something like a -fclangir-analysis-only (btw, it's a rather simple change to do that).

Fair enough summary. I'd like to see if I can make a simple patch.

[ChuanqiXu9]

Sent #638

BTW, when I test it with a real world project (https://github.com/alibaba/async_simple), I met some crashes when generating the CIR. I'd like to work on it.

[bcardosolopes]

@ChuanqiXu9 thanks the PR, will take a look soon. I bet it crashes cause we still have lots of C++ stuff to support, but being able to build async_simple would be really cool, looking forward to see your contributions