Overall, should we discuss whether we want a per-dialect builder or put that on per-op (i.e, Op::create) to not have another object involved in this (the dialect builder). I know you had pointed me to an earlier discussion, I didn't get an opportunity to carry it forward.

Rebase

Review feedback

Looks ok. In general if there is a control flow edge from parent->region, the values flowing along may not necessarily be the parent operands, and if there is control flow edge from a region->parent, the values flowing may not necessarily flow into parent results. But the current RegionBranchOpInterface is designed to model this, so this looks ok.

Add comment for BlockRange

Review feedback

Remove double private

2 documentation typos, otherwise looks good to me.

Address review comments

Thanks. Filed https://bugs.llvm.org/show_bug.cgi?id=47095 to tract the more general mechanism for doing this.

Fix comment

In D85060#2203065, @jpienaar wrote:

In D85060#2191402, @jurahul wrote:

I agree. A more general solution might be to generate all "collective" variants first, and then have a way for the build methods that will be ambiguous with any of them automatically filtered out, so that we don't have to guard their generation, just their emission. That might need the OpMethodSignature to have more structure than the current string members. I will file a bug for this assuming folks agree.

Why not have opClass.newMethod flag this? If adding a new method to the class with the same signature, flag it (return nullptr or some such, depending on where the collision occurs it is either fine or an error). Start with the build methods users requested first and then add autogenerated ones as long as they don't conflict. Then we don't have to do gymnastics here. I'd say even the non-collective ones are the more user friendly ones. Although in cases of conflict it provides the same signature so perhaps it doesn't matter which one gets generated.

Address clang-tidy warnings

Rebase

Thanks. @jpienaar, waiting to give you an opportunity to look as well.

Fix a clang-format warning

Address nits

Remove OperationSupport.h include

I did run clang-format, giving it another go.

Review feedback

I agree. A more general solution might be to generate all "collective" variants first, and then have a way for the build methods that will be ambiguous with any of them automatically filtered out, so that we don't have to guard their generation, just their emission. That might need the OpMethodSignature to have more structure than the current string members. I will file a bug for this assuming folks agree.

Remove commented out code.

Fix flang build failure, address some clang-tidy issues

Remove FuncOp::getArgument()

I have added a comment explaining why I am testing these 3 combinations in particulat:

I think you have a reason for this configuration, but it isn't clear just looking at the code why (for example) multiple variadic args need not be tested.

Address review comment

@ftynse, I read your document a bit, but another idea came to my mind which seems like an incremental change. Instead of the per-dialect builder you had suggested:

Agreed, in certain instances if clarity is desired, an explicit TypeRange{} can be still be added. But in many cases, things may be clear enough that the extra 'TypeRange{}' or ValueRange{} may be just noise, which is what I am attempting to address here. We have some instances within MLIR, but I suspect several out-of-tree instances that would read easier without these casts.

Cleanup leftover macro code

This is my attempt to remove the use of Macros. With this, we essentially need one specialization class for each function we want to specialize. I tried to go down a different route as well, creating an instance of an (empty) specialization object with a templated () operator. The hope was that we can define this class just once, and say the builder has an instance of this class called 'create' and we could do something like

Eliminate macros

Review feedback