This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Make MemRef element type extensible
ClosedPublic

Authored by ftynse on Jun 7 2021, 9:30 AM.

Details

Summary

Historically, MemRef only supported a restricted list of element types that
were known to be storable in memory. This is unnecessarily restrictive given
the open nature of MLIR's type system. Allow types to opt into being used as
MemRef elements by implementing a type interface. For now, the interface is
merely a declaration with no methods. Later, methods to query, e.g., the type
size or whether a type can alias elements of another type may be added.

Harden the "standard"-to-LLVM conversion against memrefs with non-builtin
types.

See https://llvm.discourse.group/t/rfc-memref-of-custom-types/3558.

Depends On D103826

Diff Detail

Event Timeline

ftynse created this revision.Jun 7 2021, 9:30 AM
ftynse requested review of this revision.Jun 7 2021, 9:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 7 2021, 9:30 AM

Can you add a link to the discussion for this?

mlir/docs/Dialects/Builtin.md
36

This looks wrong, BuiltinTypeInterfaces?

mlir/include/mlir/IR/BuiltinTypes.td
315

What about vector types implementing MemRefElementTypeInterface?

ftynse updated this revision to Diff 350365.Jun 7 2021, 11:04 AM
ftynse marked an inline comment as done.

Address review.

Can you add a link to the discussion for this?

https://llvm.discourse.group/t/rfc-memref-of-custom-types/3558

mlir/include/mlir/IR/BuiltinTypes.td
315

Only vector types or all allows builtin types? AFAICS, built-in types don't implement any interfaces yet so I hesitated to add one.

rriddle accepted this revision.Jun 8 2021, 1:24 AM

Can you add a link to the discussion for this?

https://llvm.discourse.group/t/rfc-memref-of-custom-types/3558

Sorry, I meant can you add it in the commit description?

I honestly would have expected more situations that memref element type was being hardcoded.

mlir/include/mlir/IR/BuiltinTypes.td
252

I wonder if we should put these in a BuiltinTypeInterfaces file instead? I don't feel that strongly either way right now, but might if we end up putting this on the other builtin types (easier to ensure it's defined before used)

This revision is now accepted and ready to land.Jun 8 2021, 1:24 AM
rriddle added inline comments.Jun 8 2021, 1:26 AM
mlir/include/mlir/IR/BuiltinTypes.td
315

They are all builtin types, so if it makes sense to have it on there I would just do it. Given they are all in the same lib, avoiding it doesn't really get us much (and will require hand coding them in anyways).

ftynse edited the summary of this revision. (Show Details)Jun 8 2021, 2:00 AM
ftynse marked an inline comment as done.Jun 8 2021, 2:09 AM

Can you add a link to the discussion for this?

https://llvm.discourse.group/t/rfc-memref-of-custom-types/3558

Sorry, I meant can you add it in the commit description?

I did. Arc doesn't seem to pick up amended commit messages, changed it through the web interface as well.

I honestly would have expected more situations that memref element type was being hardcoded.

Most of the in-tree uses have extra checks on the element type, e.g., SPIR-V only accepts memrefs of integers.

mlir/include/mlir/IR/BuiltinTypes.td
252

Will do in a separate commit in case we want to revert it.

This revision was landed with ongoing or failed builds.Jun 8 2021, 2:11 AM
This revision was automatically updated to reflect the committed changes.
ftynse marked an inline comment as done.

I did. Arc doesn't seem to pick up amended commit messages, changed it through the web interface as well.

You need to pass the --verbatim option to arc.