This is probably difficult to fix, but while working on bug 1353170 I noticed that when scalar replacement fails it was almost always because we encountered a use by a phi. I am actually not really sure why we got that phi even, my guess was OSR, but that should probably be checked. I am kind of hoping that those phis are not actually necessary and we just have to eliminate them before running scalar replacement. Scalar replacement seems to run relatively early, if it ran later we could potentially eliminate instructions that would prevent scalar replacement otherwise?

(In reply to Tom Schuster [:evilpie] from comment #0) > Scalar replacement seems > to run relatively early, if it ran later we could potentially eliminate > instructions that would prevent scalar replacement otherwise? The reason it runs that early because it wants to have all original uses, without any pass already tempering with the uses.

(In reply to Tom Schuster [:evilpie] from comment #0) > […], if it ran later we could potentially eliminate > instructions that would prevent scalar replacement otherwise? I agree and I initially tried that, but I tried and failed to move Scalar Replacement after the ApplyType phase, but this was harder than expected because the ApplyType and later phases are (strangely) not re-entrant. We want to run the ApplyType phase after Scalar Replacement to at least ensure that the folded load and store have the correct types, which might not always be true. (see Bug 1165348 and its dependencies) Instead I took the approach of using Branch Pruning, to remove the Phis which are in the way of optimizing the ArrayIteratorNext function.