Do you also have to update TransformDialect::verifyOperationAttribute?

Has this failure been clearly root-caused to this patch? Because I have really hard time seeing how SCF bufferization tests are related to this change.

Feel free to commit such changes directly.

Address review

It's okay to reland.

Remove code repetition by turning pattern-based applyToEach into a trait.

Will do some deduplication here.

This looks like an unrelated flang failure

Mostly code motion, didn't go beyond the screening for obvious layering problems.

Address review.

The gpu testcase is based on the pass-pipeline of cubin，the current compiler is not supported.

Nice, thanks!

Sorry for delay, already-approved patches don't show up in the review stream :(

Please add a test. The IR in the bug is a good start for the test, but can be simplified further.

Revise

Could you please rebase?

There isn't sufficient context to justify the change in the commit description, and the change itself doesn't seem to do anything else than lifting function argument attributes from LLVM IR to the Func dialect level. Yes, there is SPIR-V, but the change does not include the lowering to SPIR-V or even a description of how it can be done. Blindly copying LLVM IR is acceptable in the LLVM dialect, but not at the higher-level abstractions such as Func. It is unclear to me what these attributes would even mean in the full generality of what MLIR type system allows. For example, what is a writeonly tensor? How do two SPIR-V types noalias? How do even two memrefs noalias when the default conversion to LLVM produces two pointers that precisely do alias each other?

Could you check if the translation works in the opposite direction, too?

Do we need to also update the lowering to LLVM? It may assume type is always index and end up using a different bitwidth.

LGTM when the last comment is addressed, but I'd like an opinion from @nicolasvasilache on the promotion logic.

We can have test for this, but we probably don't want this to be on the _main_ build path.

In D144883#4161426, @agozillon wrote:

After a little bit of time going over the suggested change of ditching convertModuleOperation and using the existing convertOperation infrastructure, I can see two ways of doing it:

• Teach the default LLVMTranslationInterface::convertOperation to ignore builtin.module and gpu.module and return success, but this also means removing the error output for not finding a dialect interface for an operation inside of the ModuleTranslation::convertOperation function, otherwise we can hoist this ignore from LLVMTranslationInterface::convertOperation to ModuleTranslation::convertOperation and keep the error emission.
• Create and register a LLVMTranslationInterface for gpu and builtin dialects that return success and do nothing else.

I think you were meaning the latter, I am happy to do either, or even another alternative if I have misunderstood what you mean!

Note that many other tools are not directly "used" upstream, mlir-reduce, mlir-parser-fuzzer, etc. They are nevertheless useless.

I don't see why this needs to be deleted. It was used to generate the initial ODS for some intrinsics and is still useful for adding new target-specific ones. It is not used in the build process because the complexity of adding a stage to the build process does not justify it.

This allows existing dialect modules such as gpu.module to continue to not do dialect specific lowering, allowing them to opt in or out based on their dialects needs.

Why does it have to be a separate interface function? Module is just the builtin.module operation, it looks like we can just call convertOperation for it and teach the default translation to do nothing with it.

Nice, almost there, thanks you!

Could we have a test?

These patterns look very similar, any chance they can be generalized somehow?