Bug 167119 – [JSC] Handle parseInt in DFG / FTL for kraken crypto-ccm

• Status: NEW
• Component: JavaScriptCore

[Yusuke Suzuki]

kraken crypto-ccm repeatedly calls parseInt function.
I think we have a chance to optimize it by handling it in DFG, because

1. typically the second `radix` parameter is constant! We typically call it in the form like `parseInt(xxx, 10)`. So in that case, many checks can be dropped.
2. typically the first parameter is string. We can use StringUse to avoid string type check & conversions in parseInt function.

[Saam Barati]

(In reply to comment #0)
> kraken crypto-ccm repeatedly calls parseInt function.
> I think we have a chance to optimize it by handling it in DFG, because
> 
> 1. typically the second `radix` parameter is constant! We typically call it
> in the form like `parseInt(xxx, 10)`. So in that case, many checks can be
> dropped.
> 2. typically the first parameter is string. We can use StringUse to avoid
> string type check & conversions in parseInt function.

I was looking at this too last Friday!

Some more details, for Kraken specifically:
- Radix is always (almost) the number 16
- String is always a rope (I think a substring style rope)

[Saam Barati]

I was also thinking that making String.prototype.substr an intrinsic could help performance on some kraken tests.