https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/LLVMIR/NVVMOps.td as an example. We also have support in mlir-tblgen to generate the boilerplate for ops given LLVM IR intrinsic definition file, example of usage: https://github.com/llvm/llvm-project/blob/main/mlir/test/mlir-tblgen/llvm-intrinsics.td

Intermediate coro/runtime operations will allow to run transformations on a higher level IR and do not try to match IR based on the LLVM::CallOp properties.

Although async.coro is very close to LLVM coroutines, it is not exactly the same API, instead it is optimized for usability in async lowering, and misses a lot of details that are present in @llvm.coro intrinsic.

We generally use code review for everything except build unbreaks, reverts and minor syntactic changes such as typos.

Not sure about this one... I can understand the rationale, but this starts to diverge from C++/ODS, which already has suboptimal documentation and I'm apprehensive of the complexity it might add. If we agree we want to put result types after operands, we should be doing so consistently and that could be a problem for generating builders automatically if we decide we want that.

Hmm, this change actually makes Python API align on C++ API. I don't remember if there was a good reason to swap the order in C.

Matches how all of the other shaped types are declared.

Thank you!

We can't test for this because the Euclidean GCD algorithm is still correct and terminates with machine division (about efficiency, I am not sure).

Please consider avoiding "advanced" markdown features in the commit messages, a lot of people look at them in the terminal and it may be hard to parse

In D94551#2495343, @nicolasvasilache wrote:

On one hand, it's great to see minimal additional patterns translate to new capabilities, very nice!

OTOH, this has grown far beyond a few reasonable abstraction gap jumps, even for a prototype.
As time passes and the abstraction gap grows between the input and the output, the more difficult it will be to break down and refactor into composable pieces.

I am curious what the expected integration will look like and what other features you want to prototype before this integration can start?
For instance, it seems unlikely to me that the tests, as they are written, will be gradually ported to new abstractions.
One outcome that I would find unfortunate is whether people actually start to rely on all the functionality needing to be kept green at all times..

Thoughts?

Yay!

I took your name and email from Github commits. Please consider sending patches with Arcanist to preserve author (and base revision) info.

Looks like a duplicate of D94496

Rebase

Address review

Is it always unnecessary or is there a possibility that it still might be (e.g., async pointer)?

Rebase.

In D94216#2486231, @xgupta wrote:

@ftynse please commit the revision, I don't have commit access.

It looks like something went wrong when updating the second revision and the diff now only contains the comment change. Note that if you use arc diff on a branch of multiple commits, you must specify the commit that the branch is based on rather than HEAD^, which is merely the previous-to-head commit.

Address review

FYI, if you send commits with arcanist, the committer credentials are preserved.

In D92485#2483827, @Hardcode84 wrote:

Can someone merge this, please?

Thanks for iterating on this!

Address review