Bug 167119 - [JSC] Handle parseInt in DFG / FTL for kraken crypto-ccm
Summary: [JSC] Handle parseInt in DFG / FTL for kraken crypto-ccm
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-17 09:06 PST by Yusuke Suzuki
Modified: 2017-01-17 11:29 PST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.