[Mlir-commits] [mlir] Folding extract_strided_metadata input into reinterpret_cast on constant layout (PR #134845)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Tue Apr 8 14:16:00 PDT 2025


================
@@ -1948,6 +1948,27 @@ OpFoldResult ReinterpretCastOp::fold(FoldAdaptor /*operands*/) {
     if (auto prev = src.getDefiningOp<CastOp>())
       return prev.getSource();
 
+    // reinterpret_cast(extract_strided_metadata(x)) -> reinterpret_cast(x).
+    //
+    // We can always fold the input of a extract_strided_metadata operator
+    // to the input of a reinterpret_cast operator, because they point to
+    // the same memory. Note that the reinterpret_cast does not use the
+    // layout of its input memref, only its base memory pointer which is
+    // the same as the base pointer returned by the extract_strided_metadata
+    // operator and the base pointer of the extract_strided_metadata memref
+    // input. This folding is only profitable when the reinterpret_cast
----------------
ivangarcia44 wrote:

The root cause of the test regression I mentioned was that the ReinterpretCastOpExtractStridedMetadataFolder rewrite pattern was optimizing the expand_strided_metadata / reinterpret_cast pair. I moved my change from the fold method to this rewrite pattern, and by doing that, the conflict mentioned above was gone.

This allowed me to do the expand_strided_metadata's input into the reinterpret_cast input unconditionally, which simplified the code. 

For Matthias initial question ("Why is this folding only profitable when the offset, sizes, strides are constant? That seems odd..."): It could be argued that folding the input of the expand_strided_metadata into the reinterpret_cast is always profitable. It is even more profitable when DCE eliminates the expand_strided_metadata, which usually happens for static offsets/strides/sizes. But with my newest change, the folding is always going to kick in, given that the ReinterpretCastOpExtractStridedMetadataFolder rewrite pattern's original transformation does not kick in.



https://github.com/llvm/llvm-project/pull/134845


More information about the Mlir-commits mailing list