The change from IonBuilder to WarpBuilder broke some parts of scalar replacement. Scalar replacement of arrays is mostly fixed by bug 1697648. The one exception is StoreElement when needsHoleCheck is true, which comes from JSOp::SetElem. (For JSOp::InitElem, needsHoleCheck is false and we already support it.)

The problem is that storing to a hole may be observable if there is an indexed setter property on Array.prototype or Object.prototype, so we have to be sure that we don't scalar-replace any StoreElement that might write to a hole.

There are a couple of possibilities. The first is to somehow track (either during scalar replacement, or as a separate optimization pass) which indices have definitely been initialized with non-hole values, and use that information to guide scalar replacement.

The second is to use the fuse idea we've talking about for a while. As far as I can tell, so long as there are no indexed properties on Object.prototype or Array.prototype, we don't have to worry about holes. If we stored a fuse value somewhere to indicate whether each prototype had been modified, then we could implement a much more limited version of constraints and invalidate the warp script when the fuse is broken. I think there's a nice way to implement this with CacheIR, where the baseline stub loads the actual value of the fuse and checks it, and the transpiler turns that into a no-op and a constraint.

(When this is fixed, we can enable the arrayCond case in ion/recover-arrays.js.)