This is an archive of the discontinued LLVM Phabricator instance.

[NFC] Create a AllocLikeOpInterface and make memref::AllocOp, memref::AllocaOp and gpu::AllocOp implement it.
Needs RevisionPublic

Authored by arnab-oss on Sep 22 2022, 4:12 AM.

Details

Summary
  • Create AllocLikeOpInterface and put the common methods used by memref.alloc, mermen.alloca and gpu.alloc there.
  • Instead of checking explicitly for alloc or alloca ops, use hasSingleEffect().

Event Timeline

arnab-oss created this revision.Sep 22 2022, 4:12 AM
arnab-oss requested review of this revision.Sep 22 2022, 4:13 AM
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
arnab-oss updated this revision to Diff 462132.Sep 22 2022, 4:28 AM

Make gpu.alloc op implement AllocLikeOpInterface

arnab-oss updated this revision to Diff 462137.Sep 22 2022, 4:56 AM

Refactoring

arnab-oss retitled this revision from Create a AllocLikeOpInterface and make memref::AllocLikeOp and gpu::AllocOp implement it. to [NFC] Create a AllocLikeOpInterface and make memref::AllocOp, memref::AllocaOp and gpu::AllocOp implement it..Sep 22 2022, 5:00 AM
arnab-oss edited the summary of this revision. (Show Details)
bondhugula edited reviewers, added: csigg; removed: aartbik.Sep 22 2022, 7:34 PM

This is looking good to me. Please pull out changes unrelated to AllocLikeOpInterface into a separate revision (the ones just switching to hasSingleEffect).

mlir/lib/Dialect/Affine/Transforms/LoopFusion.cpp
1967 ↗(On Diff #462137)

This change isn't related to the AllocLikeOpInterface; this and other similar changes can go into another revision.

mlir/lib/Dialect/Affine/Utils/Utils.cpp
1071

The change to include GetGlobalOp is unrelated to this PR (and not proper as well) - it should be dropped.

ftynse requested changes to this revision.Oct 5 2022, 1:31 AM
ftynse added a subscriber: ftynse.

I would expect a new top-level interface (in lib/Interfaces) to go through the RFC process.

I have concerns about the interface design. Specifically, it appears to be promoting details specific to operations from one dialect (memref.alloc(a)) such as the fact that the result of an allocation is a memref (it's not, we have allocations in LLVM and SPIR-V that produce different types), that it has alignment defined as integer, and that it has some symbol operands presumably related to memref's affine layouts. If this were to live in lib/Interfaces, it should make either cover wider range of allocation-like operations or make a clear case as to why this is not desired accompanied by a name change.

mlir/include/mlir/Dialect/GPU/IR/GPUOps.td
937–954

I suppose these are only necessary because the dialect doesn't emit accessor using the prefixed form? Make sure to rebase this commit because the GPU dialect must have been switched to the prefixed form - https://discourse.llvm.org/t/psa-raw-accessors-are-being-removed/65629.

mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td
103–120

Ditto.

mlir/include/mlir/Interfaces/AllocLikeOpInterface.h
1 ↗(On Diff #462137)

Please use the correct header line.

mlir/include/mlir/Interfaces/AllocLikeOpInterface.td
1 ↗(On Diff #462137)

Please follow the (implicit) convention from other files for this line: the file name is left aligned, the file type is right aligned, and the entire line fits into 80 cols.

9 ↗(On Diff #462137)

This looks wrong.

20 ↗(On Diff #462137)

Type is not mandatory for allocations, can be just bytes.

26 ↗(On Diff #462137)

Memref is not a mandatory concept for allocating memory, I would rather not enshrine it in the top-level interface.

27 ↗(On Diff #462137)

Does it have to be a vector (copy) of values? Can't it be an OperandRange, a ValueRange or something similar?

mlir/lib/Interfaces/AllocLikeOpInterface.cpp
1 ↗(On Diff #462137)

Nit: 80 cols.

This revision now requires changes to proceed.Oct 5 2022, 1:31 AM