PTOViewToMemref should canonicalize addptr uniformly for low-level pointer consumers

[Zhendong404]

Problem

pto.addptr is currently handled in PTOViewToMemref in a consumer-specific way. The existing folding logic only covers a small whitelist of users such as:

• make_tensor_view
• scalar load/store
• a few initialization ops

When an addptr result is consumed directly by other low-level pointer users, especially memory-transfer style ops, the offset is not canonicalized into the memref/view world early enough. The later cleanup path then either leaves the addptr stranded or reports an unsupported pattern.

This makes addptr support fragile: whether a program works depends on which op happens to consume the pointer, not on whether the pointer arithmetic itself is semantically valid.

Why this matters

This is a general compiler pipeline issue rather than a testcase-specific one:

• frontends can legitimately produce ptr<gm> plus offset and feed it into low-level ops
• new ops may hit the same failure unless they are added to another ad hoc whitelist
• fixing this per consumer is easy to miss and does not scale

Suggested direction

Handle pto.addptr with a uniform canonicalization rule in PTOViewToMemref instead of special-casing individual consumers.

A more robust approach would be:

1. Convert addptr(base, offset) into an offset-bearing memref/view representation as early as possible.
2. Let downstream passes operate on that canonical representation.
3. Only lower back to raw pointer arithmetic at the final stage if the backend still requires raw pointers.

memref.subview or an equivalent view-like representation should be sufficient for most cases.

Expected benefit

• addptr semantics become independent of the specific consumer op
• fewer consumer-specific folds in PTOViewToMemref
• better coverage for future low-level ops without additional pass patches
• easier reasoning about pointer offsets across the pipeline