Bug 288657
| Summary: | [JSC] Still optimize String.at, .charAt, .charCodeAt, and .codePointAt in DFG when called with no arguments | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | David Degazio <d_degazio> |
| Component: | JavaScriptCore | Assignee: | David Degazio <d_degazio> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
David Degazio
Currently, when we detect one of these intrinsics in the DFG bytecode parser, we check if the argument count including this is greater than or equal to 2, and if it's not, we don't turn the call into an intrinsic node. However, when calling one of these functions with no arguments, i.e. "abc".charAt(), the second argument is undefined. Per the spec (https://tc39.es/ecma262/#sec-string.prototype.charcodeat), we first call ToNumber(undefined) which returns NaN, and then ToIntegerOrInfinity(NaN) which returns 0. So, when we don't pass any arguments, it's the same as passing a constant 0 - and instead of pessimizing the call we should just generate the intrinsic node with a zero operand.
I didn't really expect this to be super common, but especially for .charCodeAt() and .codePointAt() it seems like there are quite a few occurrences of this pattern on GitHub. And there's a single occurrence of .charCodeAt() in tagcloud-SP on JetStream 2. So we should probably be able to handle this case.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/145696925>
David Degazio
Pull request: https://github.com/WebKit/WebKit/pull/41459
EWS
Committed 291263@main (b6c35f4cd181): <https://commits.webkit.org/291263@main>
Reviewed commits have been landed. Closing PR #41459 and removing active labels.