This is an archive of the discontinued LLVM Phabricator instance.

[mlir][MemRef] Make reinterpret_cast(extract_strided_metadata) more robust
ClosedPublic

Authored by qcolombet on Oct 11 2022, 6:29 PM.

Details

Summary

Prior to this patch the canonicalization pattern that turns reinterpret_cast(extract_strided_metadata) into cast was only applied when all the input operands of the reinterpret_cast are exactly all the output results of the extract_strided_metadata.

This missed simplification opportunities when the values would have hold the same constant values, but yet, come from different actual values.

E.g., prior to this patch, a pattern of the form:

%base, %offset = extract_strided_metadata %source : memref<i16>
reinterpret_cast %base to offset:[0]

Wouldn't have been simplified into a simple cast, because %offset is not directly the same value object as 0.

This patch teaches this pattern how to check if the constant values match what the results of the extract_strided_metadata operation would have hold.

Note: This patch will be helpful to keep nice MLIR outputs when I push the patch to do the forwarding of statically known information as part of a folding of extract_strided_metadata.

Diff Detail

Event Timeline

qcolombet created this revision.Oct 11 2022, 6:29 PM
qcolombet requested review of this revision.Oct 11 2022, 6:29 PM
mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp
1926–1962

More doc plz, this is much more complex behavior now.

Basically the success cases are:

  1. the source buffer of reinterpret_cast comes from extract_strided_metadata memref and
  2. all offsets, sizes and strides are statically known to be equal.

Some small IR examples would be good too (fold case and cast case)

1939

This feels like a very clunky API to use ..

Can we merge the OFR and int64_t into a single vector keeping the most static information and only directly compare equality ?

I can't tell offhand if whether this is possible or whether the logic allows for more complex mixings of Value vs int comparisons.

2004

multi-line code requires braces

qcolombet added inline comments.Oct 13 2022, 8:28 AM
mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp
1939

Can we merge the OFR and int64_t into a single vector keeping the most static information and only directly compare equality ?

I don't know how much it would help API-wise in the sense that the tricky bit is to get this information to beginning with. (I.e., what is currently done in sameValueOrConstant and more particularly the lambda getConstant.)

qcolombet updated this revision to Diff 467615.Oct 13 2022, 3:03 PM
  • Add comments
qcolombet marked an inline comment as done.Oct 13 2022, 3:05 PM
qcolombet added inline comments.Oct 13 2022, 3:41 PM
mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp
1939

Looking at this again, I don't see a whole lot of simplification without some code duplication (which is what I wanted to avoid in the first place).

The annoying part is, to get the most static information, we need both the OpFoldResult (to get the index value or to crack open the related arith.constant) and the related int64_t that we deduced from the type. I.e., in terms of API, we need both A and constantA to get the most static information. (And we also need to know if constant is dynamic.)

If we were to introduce a getMostStaticInformation it would essentially look like the getConstant lambda. Then for the checks themselves, we would have to replicate the logic that compares two "most static information". (I.e. what lives in sameValueOrConstant right now.

Ideas?

nicolasvasilache requested changes to this revision.Oct 27 2022, 8:16 AM

Discussed offline, the way to go here is to add helpers to each op that encode the best efforts mixed static/dynamic semantics and are op specific.

mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp
1938

if we use zip here, this function can go away

1997

can we add this to the op itself to return a vector of opfoldresult which best effort contains the Value or Attr extract from the type.

2005

can we use a zip to drop the need for a vector in this complex API ?
Here and below

This revision now requires changes to proceed.Oct 27 2022, 8:16 AM
qcolombet updated this revision to Diff 472467.Nov 1 2022, 5:38 PM
  • Introduce getConstifiedMixedXXX methods for ReinterpretCastOp and ExtractStridedMetadataOp
  • Use this new method to simplify the implementation of reinterpret_cast(extract_strided_metadata)
qcolombet marked an inline comment as done.Nov 1 2022, 5:51 PM

Hi @nicolasvasilache,

Please take another look.

I've introduced new methods to get the most constant values of the sizes, strides, and offset for extract_strided_metadata and reinterpret_cast (see getConstifiedMixedXXX methods; BTW suggestions for a better name are appreciated!)

The "complexity" is now all hidden in constifyIndexValues and the reinterpret_cast(extract_strided_metadata) combine looks straight forward (no zip, no function ptr indirection etc.).

Cheers,
-Quentin

mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td
930

We'll probably want these methods to be part of an interface.
ViewLikeInterface could have been a candidate but extract_strided_metadata doesn't conform to it, so we likely will need to introduce something else.
For now, I just added the methods where I needed them.

mlir/lib/Dialect/MemRef/IR/MemRefOps.cpp
145

I acknowledge that this API is complicated, but it is not meant to be used directly.
This represents the meat of what the getConstifiedMixedXXX methods do, thus we have to support size, strides, and offset.

169

I'll do an RFC on how to properly fix that.
I have a wip patch for that, but it's getting longer than expected to fix all the places.

I wanted to unblock this patch, hence the workaround.
Let me know if you want me to file a bug for the proper fix.

1432

@nicolasvasilache
This refactoring is not required but allows to remove some code.
I'm happy to leave it out if you prefer the previous version.

1997

Done in getConstifiedMixedXXX methods.

nicolasvasilache accepted this revision.Nov 9 2022, 11:52 AM

Sorry for the delay . let's go with this.
The API is indeed more complex than we'd like but at least it is well isolated form users so I am fine for now.

This revision is now accepted and ready to land.Nov 9 2022, 11:52 AM
This revision was automatically updated to reflect the committed changes.
qcolombet marked an inline comment as done.