Remove uses of std::reduce

Reopen, as buildbot failed because of std::reduce

Update to latest main

Update to main

@Groverkss, my understanding is that since River accepted the patch, you should be able to land it as long as you fixed his comments (which I feel you did).

Ping @Mogball

Sorry for the delay!
This looks good to me!

I'm fine with the current naming!
In any way, we need separate files for the invalid definitions, so we can't really merge them!

Update to main

Update to main

Update to main

@Mogball, is that good to merge?

Nice!
I added more comment, notably in the implementation of the region verifier. I think there is currently a bug at least!
For the testing files, we can have valid files directly in the regions-ops.irdl.mlir, it's just that if we do, we cannot load them to test their implementation.
This is why I put all valid files in testd.irdl.mlir, and the one failing in a separate file!

Nice! For the mlir::Value, the solution is to wrap the value type in a TypeAttr. This is exactly how operands are handled for instance.

Address comments, and add missing tests

That looks like a nice first step to me!
I think the things I would change are:

• Adding an !irdl.region type
• Making that by default, irdl.region do not constrain the number of blocks
• Maybe changing the format of irdl.region to make it explicit that we are constraining the number of arguments to 0 if no arguments are provided

Address comments

Perfect! Thanks a lot!

You should add the check in the verifier rather than in the loading function.
When we create any IRDL program (even if we don't load it), it should trigger an error.
Can you also add a test for that?

I'm not sure if it's needed because this rule is enforced by the operation parser, isn't it?
But on the other hand I may be missing something. If you think that the verifier is needed, could you please provide a test case that tests this check? I couldn't come up with any.

Oh also, could you write a verifier in the operation that attributeValues and attributeValueNames have the same length?

Thanks a lot for the patch!
I added some inline comments.

core: Update to main

Update to main

I'll fix the name of the other IRDL operations (as they are inconsistent) in another patch to make this cleaner!

Revert change of other operation names

Address comments

Fix documentation

Address comments, and rebase on main

Update to main

Fix bug triggered by clang-10, and update to latest LLVM

This was triggering a buildbot failure, I'm currently investigating this

Rebase to head

Address comments

Rebase to main

For the tri-state problem, I think that we want to let users use empty Attribute in their Attribute parameters.
For instance, if you would define a vector in IRDL, you may use the null attribute to represent the vector encoding.

Address comments

Improve includes, and remove unneeded namespace prefixes

ping @rriddle, just to know if I should write unit tests or if the filecheck tests in D145734 are sufficient.

Rebase to latests LLVM, and attempt to fix compilation

All of these are tested in D145734 with filecheck. Do you think I should still add additional unit tests for these?

Address comments

It should be good now, I forgot dependencies in the CMake!

Fix MLIRIRDL CMake requirements

Thanks for reverting it, I'm trying to reproduce it locally and find a fix!

Right, I'll try to ask for commit access, I wasn't sure what are the requirements for it!

I just got an email with two buildbot failures:
https://lab.llvm.org/buildbot/#/builders/181/builds/16214
https://lab.llvm.org/buildbot/#/builders/180/builds/14593

Thank! Could you land this for me? I do not have commit access.

Rebase to latest LLVM

Address comments

Update comment (register -> load)

In D144693#4187242, @mehdi_amini wrote:

Sure, but that means that no pass will every create entities (Operation/Type/Attribute) defined by an IRDL dialect? If you think otherwise: how would that happen?

In D144693#4186106, @mehdi_amini wrote:

I feel like you're using "register" when it is actually more "loading" here. (I'm not sure IRDL has a concept equivalent to "registering" dialects?)

Coming back to this: how do we differentiate registering from loading in IRDL? Do you see some difference somehow?

In D144693#4186106, @mehdi_amini wrote:

I feel like you're using "register" when it is actually more "loading" here. (I'm not sure IRDL has a concept equivalent to "registering" dialects?)

Coming back to this: how do we differentiate registering from loading in IRDL? Do you see some difference somehow?

Document the handling of mlir::Type in IRDL.

Address additional comments

Address some comments

Rebase to main

Address comments