This is the counterpart of memref.reinterpret_cast and is useful to lift
strided memref manipulation out of the LLVM dialect.
Could you please elaborate what "resolved" means ?
My word "resolved" is likely the same as your word "folded" (but per the discussion on discourse, I think that such folding needs to be explicit as it has phase ordering constraints).
I was focusing more on "used": there really is not a constraint on where it gets used in various settings.
Recommend avoiding "late/early" in the summary - that's all application-specific and relative. Instead,
Extracts a buffer base with offset and strides
Behavior of the op when such stride info can't be extracted has been left undocumented here.
extract_metadata would be too generic a name and not reflect what this op is returning. Instead, extract_stride_metadata or extract_stride_info looks appropriate.
LGTM - but some comments to rephrase/rewrite certain things.
I think these paras need some rephrasing - the first bullet refers to LLVM lowering, but the header talks about ops needing to manipulate stride info outside the LLVM dialect. I think this is a bullet on the latter is missing.
Also, I think "... to lift the materialization of the internal logic of ops that manipulate metadata" should be rewritten better.
Beyond these, I see this extraction needed for completeness sake just like we have dim op: you can have a memref passed to a function and extracting strides, sizes etc. may be needed to subsequently say construct a new memref -- let's say with slightly different strides, sizes but based on the previous memref.
metadata -> memref metadata?
"next problem" is unclear here.
Syntax broken here: sizes:2, ...