We can inline the String.prototype.charCodeAt into TurboFan again, I had that originally, but the graphs are quite huge afterwards. I'm wondering if most of the relevant strings are sequential one-byte strings, because in that case we could just specialize to that, i.e. introduce a dedicated CheckSeqOneByteString with an appropriate Type::SeqOneByteString in TurboFan.

The StringCharCodeAt regression is repaired. The benchmark still runs faster in CS because it just hoists all the charCodeAt(constant) accesses out of the outer loop, and so it doesn't do a lot of work inside the loop. TurboFan currently doesn't peel the outer loop, so we cannot eliminate any redundant accesses from the outer loop. Assigning to jarin@ to decide whether to do the outer loop peeling as well at some point.