ClampUnsafeAccesses is too conservative

[alexreinking]

ClampUnsafeAccesses which is added by #6294 applies clamps to funcs that appear in indexing expressions, even when that func is not over-computed. We're landing the PR with this (sound, but potentially pessimizing) defect because the implementation is not straightforward, but should move to fix it soon.

[steven-johnson]

What would be involved in smartening this? A schedule optimization I was experimenting with is currently being bitten by this, and even adding explicit clamp and/or unsafe_promise_clamped doesn't get around the gratuitous-in-my-case min/max-in-the-inner-loop insertion.

[abadams]

The problem only rears its head when the caller Func is being overcomputed and, probably as a consequence of this, the called Func was overallocated and contains uninitialized values. We could try to check, for each Func, if the storage bounds equal the compute bounds. We could alternatively sniff the schedule for the current stage of the caller Func to see if overcompute is possible. I think that's just a question of whether there are any splits that aren't GuardWithIf. At this point in lowering it might be hard to tell which stage of the Func we're computing though.

One special-but-common-and-easy-to-detect case: It's safe is if the callee is compute_at somewhere inside the caller. In that case the compute bounds of the callee are known to cover all loaded values by the caller, whether or not they're necessary to cover the compute bounds of the caller, because that's how we do compute bounds inference in that case.

So perhaps the simplest change that might help is to only inject the clamp if the realization of the callee is outside the produce node of the caller.