[JSC][DFG] Make addShouldSpeculateAnyInt more conservative to avoid regression caused...
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-03-23  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [JSC][DFG] Make addShouldSpeculateAnyInt more conservative to avoid regression caused by Double <-> Int52 conversions
4         https://bugs.webkit.org/show_bug.cgi?id=169998
5
6         Reviewed by Saam Barati.
7
8         Double <-> Int52 and JSValue <-> Int52 conversions are not so cheap. Thus, Int52Rep is super carefully emitted.
9         We make addShouldSpeculateAnyInt more conservative to avoid regressions caused by the above conversions.
10         We select ArithAdd(Int52, Int52) only when this calculation is beneficial compared to added Int52Rep conversions.
11
12         This patch tighten the conditions of addShouldSpeculateAnyInt.
13
14         1. Honor DoubleConstant.
15
16         When executing imaging-darkroom, we have a thing like that,
17
18             132:< 2:loc36> DoubleConstant(Double|UseAsOther, AnyIntAsDouble, Double: 4607182418800017408, 1.000000, bc#114)
19             1320:< 1:loc38>        Int52Rep(Check:Int32:@82, Int52|PureInt, Int32, Exits, bc#114)
20             1321:< 1:loc39>        Int52Constant(Int52|PureInt, Boolint32Nonboolint32Int52, Double: 4607182418800017408, 1.000000, bc#114)
21             133:<!3:loc39> ArithSub(Int52Rep:@1320<Int52>, Int52Rep:@1321<Int52>, Int52|MustGen, Int52, CheckOverflow, Exits, bc#114)
22
23         The LHS of ArithSub says predicting Boolint32, and the rhs says AnyIntAsDouble. Thus we select ArithSub(Int52, Int52) instead
24         of ArithSub(Double, Double). However, it soon causes OSR exits. In imaging-darkroom, LHS's Int32 prediction will be broken.
25         While speculating Int32 in the above situation is reasonable approach since the given LHS says predicting Int32, this causes
26         severe performance regression.
27
28         Previously, we always select ArithSub(Double, Double). So accidentally, we do not encounter this misprediction issue.
29
30         One thing can be found that we have DoubleConstant in the RHS. It means that we have `1.0` instead of `1` in the code.
31         We can see the code like `lhs - 1.0` instead of `lhs - 1` in imaging-darkroom. It offers good information that lhs and
32         the resulting value would be double. Handling the above ArithSub in double seems more appropriate rather than handling
33         it in Int52.
34
35         So, in this patch, we honor DoubleConstant. If we find DoubleConstant on one operand, we give up selecting
36         Arith[Sub,Add](Int52, Int52). This change removes OSR exits occurr in imaging-darkroom right now.
37
38         2. Two Int52Rep(Double) conversions are not desirable.
39
40         We allow AnyInt ArithAdd only when the one operand of the binary operation should be speculated AnyInt. It is a bit conservative
41         decision. This is because Double to Int52 conversion is not so cheap. Frequent back-and-forth conversions between Double and Int52
42         rather hurt the performance. If the one operand of the operation is already Int52, the cost for constructing ArithAdd becomes
43         cheap since only one Double to Int52 conversion could be required.
44         This recovers some regression in assorted tests while keeping kraken crypto improvements.
45
46         3. Avoid frequent Int52 to JSValue conversions.
47
48         Int52 to JSValue conversion is not so cheap. Thus, we would like to avoid such situations. So, in this patch, we allow
49         Arith(Int52, Int52) with AnyIntAsDouble operand only when the node is used as number. By doing so, we avoid the case like,
50         converting Int52, performing ArithAdd, and soon converting back to JSValue.
51
52         The above 3 changes recover the regression measured in microbenchmarks/int52-back-and-forth.js and assorted benchmarks.
53         And still it keeps kraken crypto improvements.
54
55                                                    baseline                  patched
56
57         imaging-darkroom                       201.112+-3.192      ^     189.532+-2.883         ^ definitely 1.0611x faster
58         stanford-crypto-pbkdf2                 103.953+-2.325            100.926+-2.396           might be 1.0300x faster
59         stanford-crypto-sha256-iterative        35.103+-1.071      ?      36.049+-1.143         ? might be 1.0270x slower
60
61         * dfg/DFGGraph.h:
62         (JSC::DFG::Graph::addShouldSpeculateAnyInt):
63
64 == Rolled over to ChangeLog-2017-03-23 ==