In several places on the kraken benchmark IonMonkey does not emit fast paths for element accesses. While bug 832364 could help in many of these cases by emitting paths for known native accesses, there are easier fixes here that use the existing paths, as all the accessed objects are arrays. The attached patch fixes all such missing fast paths (except in cases where element access has never executed at the point of compilation). Applies on top of bug 832360 though doesn't actually depend on that bug. - Bump MIN_SPARSE_INDEX from 256 to 512. audio-beat-detection creates an array of 512 elements and fills it from the top down; this causes us to sparsify the whole thing. While this general pattern will need to be handled better in the future, this particular case is easy to fix now. - Be more tolerant when filling in types for one/off literals in global code. We saw some object literals with the same properties but slightly different property types (array of int vs. array of double) and totally forgot all type information for them. - Emit dense and typed element accesses when the object might be a primitive. On my machine these fixes improve our kraken score by 7.6% (2694 -> 2502, x86/darwin).

[Approval Request Comment] Bug caused by (feature/regressing bug #): We regressed 3.5% on kraken during the FF20 cycle. FF19 and FF21 are both fine, only FF20 took this hit. User impact if declined: A visible 3.5% regression when running the kraken benchmark Testing completed (on m-c, etc.): The full patch has been tested on m-i, m-c and aurora Risk to taking this patch (and alternatives if risky): Risk is as good as zero. This patch is a one-liner out of the full patch. It increases the size when we decide an array is small. This change has went already through aurora, m-i and m-c. String or UUID changes made by this patch: /