Bug 151875 – Snippefy shift operators for the baseline JIT.

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Lam]

Patch coming.

[Radar WebKit Bug Importer]

<rdar://problem/23763289>

[Mark Lam]

Created attachment 266665 [details]
work in progress (for archiving).

So far, the code passes the op_lshift.js, op_rshift.js, and op_urshift.js correctness tests.  However, on 32-bit only with the DFG enabled, some JSC tests are failing.

The issue seems to be due to some interplay between the DFG compiled code (which doesn't use shifts and doesn't inline) with a rshift that needs to truncate a double value before shifting.  I'm still debugging the issue.

[Mark Lam]

Created attachment 266934 [details]
proposed patch.

[Mark Lam]

Created attachment 266935 [details]
x86_64 benchmark result.

[Mark Lam]

Created attachment 266936 [details]
x86 benchmark result.

[Mark Lam]

Created attachment 266937 [details]
x86_64 benchmark result without DFG.

[Mark Lam]

Created attachment 266938 [details]
x86 benchmark result without DFG.

[WebKit Commit Bot]

Attachment 266934 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/jit/JITLeftShiftGenerator.h:39:  Wrong number of spaces before statement. (expected: 12)  [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/jit/JITRightShiftGenerator.h:45:  Wrong number of spaces before statement. (expected: 12)  [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/jit/JITRightShiftGenerator.h:46:  Wrong number of spaces before statement. (expected: 12)  [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/jit/JITRightShiftGenerator.h:47:  Wrong number of spaces before statement. (expected: 12)  [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/jit/JITRightShiftGenerator.h:48:  Wrong number of spaces before statement. (expected: 12)  [whitespace/indent] [4]
Total errors found: 5 in 15 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Mark Lam]

Perf is neutral with the DFG and FTL enabled both on x86_64 and x86.

On x86_64 without the DFG (baseline only), the following are differences were reproducible:
                                                              base64                    new64                                       
    Kraken:
       audio-fft                                         673.159+-11.037     !     692.388+-7.531         ! definitely 1.0286x slower
       stanford-crypto-aes                               229.131+-4.390      ^     204.253+-11.638        ^ definitely 1.1218x faster
       stanford-crypto-pbkdf2                            671.840+-9.638      ^     528.977+-12.468        ^ definitely 1.2701x faster
       stanford-crypto-sha256-iterative                  216.479+-6.121      ^     169.898+-5.186         ^ definitely 1.2742x faster

       <arithmetic>                                      650.406+-3.260      ^     639.740+-2.592         ^ definitely 1.0167x faster

    JSRegress:
       Int16Array-bubble-sort-with-byteLength           113.2455+-3.5086     ^    101.6507+-1.9582        ^ definitely 1.1141x faster

    AsmBench:
       cray.c                                          4232.7081+-34.7270    !   4410.9133+-42.4514       ! definitely 1.0421x slower
       dry.c                                          12149.4177+-223.7582   ^  11213.3777+-244.9304      ^ definitely 1.0835x faster
       FloatMM.c                                      10451.3692+-81.1538    ^  10200.8427+-88.6311       ^ definitely 1.0246x faster
       gcc-loops.cpp                                  74450.9260+-306.4221   ^  69896.1422+-223.8573      ^ definitely 1.0652x faster
       n-body.c                                       15987.9045+-89.8126    !  16524.1872+-111.5326      ! definitely 1.0335x slower
       Quicksort.c                                     3061.9905+-98.3666    ^   2878.1299+-41.5250       ^ definitely 1.0639x faster

       <geometric>                                     9469.6117+-55.6428    ^   9303.2576+-55.3182       ^ definitely 1.0179x faster

In aggregate, we're coming out head.

On x86 without the DFG (baseline only), the following are differences were reproducible:
    LongSpider:
       crypto-sha1                                    10232.2530+-59.5800    !  10461.1403+-160.7683      ! definitely 1.0224x slower
       <geometric>                                     2742.5505+-5.9202     ?   2766.3459+-38.7184       ? might be 1.0087x slower

    JSRegress:
       ftl-object-mul                                   598.4510+-2.7411     !    631.3698+-16.3157       ! definitely 1.0550x slower
       is-function-fold                                 109.2575+-4.2563     !    134.8597+-4.7635        ! definitely 1.2343x slower
       is-object-or-null-trickier-internal-function   
							145.7091+-8.6732     ^    128.8445+-4.1844        ^ definitely 1.1309x faster
       slow-ternaries                                   177.0378+-3.1319     !    192.0789+-6.8312        ! definitely 1.0850x slower

    AsmBench:
       bigfib.cpp                                      5738.3664+-274.1690   ?   5924.0195+-43.2240       ? might be 1.0324x slower
       cray.c                                          5441.9027+-60.4271    !   5563.7455+-25.5397       ! definitely 1.0224x slower
       dry.c                                          12110.6673+-72.7679    !  12888.6103+-34.7949       ! definitely 1.0642x slower
       FloatMM.c                                      12061.5323+-117.9651   !  12326.8108+-104.8552      ! definitely 1.0220x slower
       gcc-loops.cpp                                  78357.7505+-388.7618   !  82538.5898+-906.1952      ! definitely 1.0534x slower
       n-body.c                                       21200.1181+-93.2712    !  21777.6360+-40.0155       ! definitely 1.0272x slower
       Quicksort.c                                     2949.8094+-36.7297    !   3119.5748+-25.0695       ! definitely 1.0576x slower
       stepanov_container.cpp                         23360.5030+-78.7957    !  24059.7274+-125.1245      ! definitely 1.0299x slower
       Towers.c                                        3539.9532+-9.2085     !   3639.0267+-44.6633       ! definitely 1.0280x slower

       <geometric>                                    10705.9846+-56.4381    !  11106.0812+-17.2664       ! definitely 1.0374x slower

For the 2 tests that have a large difference, is-function-fold and is-object-or-null-trickier-internal-function, both uses a left shift.  ftl-object-mul doesn't use shifts at all.  These differences may be cause in part by cache effects.  I think we should ignore these x86 differences because they don't affect perf with the DFG enabled.

[Mark Lam]

Thanks for the review.  Landed in r193788: <http://trac.webkit.org/r193788>.