@ftynse Fixed.

@rriddle @mehdi_amini Gentle remainder :) Could you please take a look at this patch one more time? I've added more checks to OperationParser::resolveSSAUse to catch the wrong usage and add extra tests for invalid cases.

@sammccall @zturner Gentle remainder :) Could you please take a look one more time to this patch? I've excluded questionable part from it.

In D111650#3070737, @mehdi_amini wrote:

I don't think that is really what I was saying though: this does not provide a feature to elide the type only if the producer is in the same block. Right now you just poked a hole through the declarative assembly syntax which allows to make it unsafe.

Add more checks to OperationParser::resolveSSAUse to handle the misuse of the feature.

@ftynse @rriddle Addressed your comments.

@ftynse I've addressed your comments.

Addressed review comments

@bondhugula I've addressed your comments, please take a look one more time.

Addressed review comments

In D111650#3067285, @mehdi_amini wrote:

Maybe you missed my last answer on Discourse, can you take another look there?

@ftynse @bondhugula I've addressed your comments.

Updated according to review remarks

I've redone the change. Now it doesn't touch the ODS generation logic,
instead I've used Custom Directives in assembly format to implement the desired behavior.
The only change in the core part - relaxed check in the OperationParser.

In D111650#3060619, @rriddle wrote:

(Marking as general -1 for now)

In D111650#3059024, @mehdi_amini wrote:

Leaving aside your syntax issue, I don't understand a use-case where it makes sense in MLIR to have the verifyUsedOnlyInTrivialSSACFG restriction applied on the parent regions transitively. Can you elaborate on this?

Rebased to re-run pre-commit CI

Applied review remark and reverted unnecessary format changes

I've excluded questionable part (non-const references support) from the patch.
Could you please take a look one more time?

@mehdi_amini @rriddle @ftynse @aartbik @nicolasvasilache @herhut Gentle reminder, could you please take a look at this patch?

Fix llvm_canonicalize_cmake_booleans usage

@akuegel @ftynse I've just pushed a fix to upstream.

@akuegel Yes, I'm currently investigating them.

In D108505#2986623, @ftynse wrote:

Are there cases (e.g., tests) where we expect the parallel loops with unsupported mapping to persist in the IR or are we always erroring out? In the latter case, just keeping the unlowered op as illegal would still error out but with a different message (conversion failed), we can just update the message in tests in that case.

Rebased and extend NOTE/TODO comment

Rebased

@ftynse @herhut Please take a look into GPU related part.

@rriddle I've fixed your remarks

Fix review remarks

Fixed review remarks

@bondhugula I've fixed your remarks.

Applied review remarks.

@rriddle I've applied your suggestions.

Apply review remarks

In D107437#2925696, @rriddle wrote:

If this is just to avoid the generic alias in the "parent" dialect (in this case, the builtin dialect), can we just flip the iteration order of the dialect interfaces when building the alias set? I'm not sure when Optional would ever really be used outside of that use case.

Or in other words, current implementation doesn't allow to attach the same interface implementation to several objects from one dialect. And it doesn't matter if it is a single interface model for all objects or it is different model classes.

In D107274#2921570, @ftynse wrote:

I wouldn't call this a fix. Having the same class implement the interface for different objects actually sounds like a new functionality.

Actually it is shown in the test) We decompose virtual index permutation and strided form:

@nicolasvasilache I've started a discussion on discourse with this topic - https://llvm.discourse.group/t/rfc-memreftype-affine-maps-list-vs-single-item/3968

The thing is - MemRefType API allows to use lists of affine maps. But in various places there are assumption, that it contains single item (or it is empty). And sometimes those assumption is not even checked and just the first/last item is used without any check/assertion. IMHO, this makes the code base fragile.

@ftynse Thanks for clarification! Actually in our internal project we use decomposed list of affine maps exactly as in your example (separate virtual indexing permutation and strided form to get physical indexing). At least this approach doesn't contradict original MemRef design.