This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Linalg] NFC - Extract a standalone LinalgInterfaces
ClosedPublic

Authored by nicolasvasilache on Feb 3 2021, 4:53 AM.

Details

Summary

This separation improves the layering and paves the way for more interfaces coming up in the future.

Diff Detail

Event Timeline

nicolasvasilache requested review of this revision.Feb 3 2021, 4:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2021, 4:53 AM
bkramer accepted this revision.Feb 3 2021, 4:55 AM

looks good

This revision is now accepted and ready to land.Feb 3 2021, 4:55 AM

Fix cmake take 2.

More cmake pain.

mehdi_amini added inline comments.Feb 3 2021, 9:55 AM
mlir/include/mlir/Interfaces/LinalgInterfaces.h
45

Shouldn't this file be under include/mlir/Dialect/Linalg/... ?

mlir/include/mlir/Interfaces/LinalgInterfaces.h
45

Hmm I went through some effort moving it under mlir/Interfaces because virtually all interfaces live there (or in IR but not applicable here).
The precedent I went after is VectorInterfaces.

Is there a strong opinion that this should not live here?

rriddle added inline comments.Feb 3 2021, 11:47 AM
mlir/include/mlir/Interfaces/LinalgInterfaces.h
45

+1 to what Medhi says. Dialect specific interfaces should live near those dialects, this directory is intended for more general things. Affine already sets a precedent here (and a good one): https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/Affine/IR/AffineMemoryOpInterfaces.td

mehdi_amini added inline comments.Feb 3 2021, 11:51 AM
mlir/include/mlir/Interfaces/LinalgInterfaces.h
45

Something that isn't clear to me conceptually is why does it make sense to have an interface that is specific to a Dialect?

In general we introduce interfaces to decouple between what the client (a pass/analysis) wants to know and the "object" it operates on. The interface makes sense so that multiple dialects or operation can answer the query.

Is it intended that this interface would be implemented by other dialects? If so it can makes sense to have it here then.

rriddle added inline comments.Feb 3 2021, 11:54 AM
mlir/include/mlir/Interfaces/LinalgInterfaces.h
45

In general we introduce interfaces to decouple between what the client (a pass/analysis) wants to know and the "object" it >operates on. The interface makes sense so that multiple dialects or operation can answer the query.

I don't see how this is different for a single dialect? If my dialect has a bunch of operations that have similar characteristics, why wouldn't I use an interface to make my transformations simpler? Saying that interfaces only make sense inter-dialect brings us back to hardcoding operation names in transformations, which may make sense for some things but it doesn't really scale (whether that be with one dialect or multiple).

mehdi_amini added inline comments.Feb 3 2021, 12:22 PM
mlir/include/mlir/Interfaces/LinalgInterfaces.h
45

I don't see how this is different for a single dialect? If my dialect has a bunch of operations that have similar characteristics, why wouldn't I use an interface to make my transformations simpler? Saying that interfaces only make sense inter-dialect brings us back to hardcoding operation names in transformations, which may make sense for some things but it doesn't really scale (whether that be with one dialect or multiple).

I wrote multiple dialects OR operation, what I had in mind was:

-> Operation Interface: when you have multiple operations (possibly in the same dialect)
-> Dialect Interface: when you have multiple Dialects.

mehdi_amini added inline comments.Feb 3 2021, 12:23 PM
mlir/include/mlir/Interfaces/LinalgInterfaces.h
45

But I think we're on the same line that if an Operation Interface is intended for the operations in a specific dialect, then it can live within this dialect and not here :)

ok, sgtm, thanks!

nicolasvasilache retitled this revision from [mlir][Linalg] NFC - Extract an Interfaces/LinalgInterfaces to [mlir][Linalg] NFC - Extract a standalone LinalgInterfaces.Feb 3 2021, 1:46 PM

Address review.

mehdi_amini accepted this revision.Feb 3 2021, 6:11 PM
This revision was landed with ongoing or failed builds.Feb 3 2021, 11:25 PM
This revision was automatically updated to reflect the committed changes.