[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