Bug 167119

Summary: [JSC] Handle parseInt in DFG / FTL for kraken crypto-ccm
Product: WebKit Reporter: Yusuke Suzuki <ysuzuki>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: saam
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   

Description Yusuke Suzuki 2017-01-17 09:06:16 PST
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.
Comment 1 Saam Barati 2017-01-17 11:26:55 PST
(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)
Comment 2 Saam Barati 2017-01-17 11:29:44 PST
I was also thinking that making String.prototype.substr an intrinsic could help performance on some kraken tests.