This will be fun.
Created attachment 254531 [details] work in progress
Created attachment 254540 [details] a bit more
Created attachment 254551 [details] it is written
Created attachment 254595 [details] starting to do things
Created attachment 254596 [details] it's removing bounds checks Still a lot more testing to do though.
Created attachment 254597 [details] for real this time The last upload was a stale file.
Created attachment 254608 [details] adding the != relationship This will help with loops bounded by !=length or !=0, rather than the inequality.
Created attachment 254618 [details] looks pretty good This now eliminates the array bounds check and the induction variable's increment/decrement overflow check in each of these loop styles: function foo(array) { var result = 0; for (var i = 0; i < array.length; ++i) result += array[i]; return result; } function foo(array) { var result = 0; for (var i = array.length - 1; i >= 0; i--) result += array[i]; return result; } function foo(array) { var result = 0; for (var i = array.length; i--;) result += array[i]; return result; } function foo(array) { var result = 0; for (var i = 0; i != array.length; ++i) result += array[i]; return result; }
Created attachment 254673 [details] it's starting to pass tests
This is so much win. Benchmark report for SunSpider, LongSpider, V8Spider, Octane, Kraken, JSRegress, AsmBench, and CompressionBench on dethklok (MacBookPro9,1). VMs tested: "TipOfTree" at /Volumes/Data/pizlo/secondary/OpenSource/WebKitBuild/Release/jsc (r185429) "ABC" at /Volumes/Data/pizlo/tertiary/OpenSource/WebKitBuild/Release/jsc (r185429) Collected 6 samples per benchmark/VM, with 6 VM invocations per benchmark. Emitted a call to gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds. TipOfTree ABC SunSpider: 3d-cube 5.2522+-0.0637 ? 5.3453+-0.0754 ? might be 1.0177x slower 3d-morph 6.0955+-0.6972 ? 6.6495+-0.6699 ? might be 1.0909x slower 3d-raytrace 6.9005+-0.5144 6.4329+-0.0821 might be 1.0727x faster access-binary-trees 2.4729+-0.2068 ? 2.5024+-0.2880 ? might be 1.0119x slower access-fannkuch 6.2685+-0.1210 ? 6.2915+-0.1741 ? access-nbody 3.0662+-0.2447 ? 3.2768+-0.5420 ? might be 1.0687x slower access-nsieve 3.4585+-0.3304 3.4557+-0.0792 bitops-3bit-bits-in-byte 1.7137+-0.2047 1.6460+-0.0639 might be 1.0411x faster bitops-bits-in-byte 3.9757+-0.2052 3.8198+-0.3107 might be 1.0408x faster bitops-bitwise-and 2.1706+-0.1078 2.1613+-0.0365 bitops-nsieve-bits 3.3831+-0.1320 ^ 3.2180+-0.0130 ^ definitely 1.0513x faster controlflow-recursive 2.9090+-0.1822 2.8485+-0.1766 might be 1.0212x faster crypto-aes 4.9152+-0.4821 ? 4.9432+-0.3993 ? crypto-md5 2.7442+-0.0922 ? 2.8453+-0.2650 ? might be 1.0368x slower crypto-sha1 3.7282+-0.2250 3.6643+-0.2416 might be 1.0174x faster date-format-tofte 9.2598+-0.0769 ? 9.5358+-0.3491 ? might be 1.0298x slower date-format-xparb 6.5205+-0.7261 6.1547+-0.2730 might be 1.0594x faster math-cordic 3.2450+-0.2680 ? 3.2911+-0.4410 ? might be 1.0142x slower math-partial-sums 5.6660+-0.3710 ? 5.7195+-0.7247 ? math-spectral-norm 2.0806+-0.0578 ? 2.2413+-0.3977 ? might be 1.0772x slower regexp-dna 7.5214+-0.1283 ? 7.5908+-0.1729 ? string-base64 5.2126+-0.4598 ? 5.7705+-0.8675 ? might be 1.1070x slower string-fasta 7.1652+-0.1449 7.1287+-0.1970 string-tagcloud 10.2728+-0.9067 ? 10.4488+-1.1835 ? might be 1.0171x slower string-unpack-code 20.8645+-0.7341 ? 20.9869+-1.2084 ? string-validate-input 6.1214+-0.3828 5.9665+-0.0707 might be 1.0260x faster <arithmetic> 5.4994+-0.0748 ? 5.5360+-0.0873 ? might be 1.0067x slower TipOfTree ABC LongSpider: 3d-cube 893.4778+-4.2977 ! 1125.5387+-14.9048 ! definitely 1.2597x slower 3d-morph 1529.4853+-4.4786 ? 1531.2384+-6.3730 ? 3d-raytrace 694.9364+-3.3910 ? 714.1325+-48.1731 ? might be 1.0276x slower access-binary-trees 1009.9510+-5.4842 1007.2894+-7.8937 access-fannkuch 351.6922+-8.5923 339.1489+-9.6560 might be 1.0370x faster access-nbody 589.1946+-1.2794 ? 589.8350+-2.2589 ? access-nsieve 485.8809+-18.3256 477.5903+-7.8611 might be 1.0174x faster bitops-3bit-bits-in-byte 44.9884+-1.1205 44.5340+-0.8889 might be 1.0102x faster bitops-bits-in-byte 99.9028+-2.5101 ? 100.3802+-0.9174 ? bitops-nsieve-bits 421.4715+-4.9817 418.6126+-1.1040 controlflow-recursive 484.8502+-11.1032 481.7343+-10.6275 crypto-aes 703.5952+-7.4370 ^ 673.3990+-2.1696 ^ definitely 1.0448x faster crypto-md5 520.8144+-1.8768 ? 534.5755+-14.1932 ? might be 1.0264x slower crypto-sha1 720.4084+-73.5653 663.6917+-23.9593 might be 1.0855x faster date-format-tofte 724.8421+-31.0369 714.3639+-8.3922 might be 1.0147x faster date-format-xparb 811.7282+-64.4451 783.9195+-26.4259 might be 1.0355x faster hash-map 185.9707+-2.5719 ? 187.3777+-2.7201 ? math-cordic 578.5213+-4.7902 576.9253+-3.0887 math-partial-sums 513.4990+-16.9964 508.5806+-2.1580 math-spectral-norm 565.7807+-2.4077 ! 570.3999+-1.8634 ! definitely 1.0082x slower string-base64 414.2543+-7.5637 413.0341+-4.2902 string-fasta 430.0909+-4.1215 427.3119+-2.9265 string-tagcloud 195.5827+-5.6611 ? 197.2655+-3.8996 ? <geometric> 456.7465+-3.4301 ? 457.6106+-2.1812 ? might be 1.0019x slower TipOfTree ABC V8Spider: crypto 55.7027+-2.7066 ? 58.1624+-1.9861 ? might be 1.0442x slower deltablue 96.6455+-4.0267 ? 98.4035+-4.9706 ? might be 1.0182x slower earley-boyer 51.2510+-0.7040 50.6565+-0.8714 might be 1.0117x faster raytrace 42.1466+-2.3508 ? 43.4004+-1.7906 ? might be 1.0297x slower regexp 92.2725+-27.6754 84.2625+-2.2560 might be 1.0951x faster richards 87.2644+-7.1476 86.5339+-2.9325 splay 41.0767+-1.5322 39.9309+-1.7434 might be 1.0287x faster <geometric> 62.5474+-3.0063 62.3269+-1.1192 might be 1.0035x faster TipOfTree ABC Octane: encrypt 0.20285+-0.00081 ^ 0.19739+-0.00108 ^ definitely 1.0277x faster decrypt 3.65538+-0.05928 ^ 3.35824+-0.01085 ^ definitely 1.0885x faster deltablue x2 0.19371+-0.00191 0.18965+-0.00292 might be 1.0214x faster earley 0.39091+-0.00444 ? 0.40227+-0.00822 ? might be 1.0291x slower boyer 6.99226+-0.38100 6.96921+-0.28905 navier-stokes x2 5.17783+-0.01189 ^ 5.13246+-0.01985 ^ definitely 1.0088x faster raytrace x2 1.32033+-0.04674 ? 1.32538+-0.05274 ? richards x2 0.13549+-0.00482 ? 0.14440+-0.01819 ? might be 1.0658x slower splay x2 0.41237+-0.03194 0.40210+-0.00661 might be 1.0255x faster regexp x2 31.62929+-0.65396 ? 32.79144+-1.94677 ? might be 1.0367x slower pdfjs x2 42.46285+-0.27487 ? 42.54016+-0.35845 ? mandreel x2 51.31800+-0.32065 ^ 50.25441+-0.62393 ^ definitely 1.0212x faster gbemu x2 45.76554+-3.93118 45.48865+-2.52585 closure 0.56266+-0.00343 ? 0.56567+-0.00328 ? jquery 7.35740+-0.05259 ? 7.61338+-0.57767 ? might be 1.0348x slower box2d x2 13.15896+-0.84837 12.79954+-0.09940 might be 1.0281x faster zlib x2 385.96742+-17.01030 ? 397.56117+-5.22140 ? might be 1.0300x slower typescript x2 778.54810+-4.58329 775.21724+-7.37991 <geometric> 6.73337+-0.07607 6.73142+-0.07542 might be 1.0003x faster TipOfTree ABC Kraken: ai-astar 239.083+-11.765 ^ 219.571+-1.176 ^ definitely 1.0889x faster audio-beat-detection 82.150+-1.289 ? 83.038+-3.477 ? might be 1.0108x slower audio-dft 120.988+-3.263 119.290+-1.815 might be 1.0142x faster audio-fft 71.154+-2.527 ? 71.335+-2.109 ? audio-oscillator 90.611+-1.422 89.253+-0.484 might be 1.0152x faster imaging-darkroom 104.986+-1.860 ? 105.198+-2.032 ? imaging-desaturate 65.188+-2.756 61.472+-1.336 might be 1.0604x faster imaging-gaussian-blur 112.915+-7.053 107.833+-2.311 might be 1.0471x faster json-parse-financial 48.038+-1.565 46.412+-1.652 might be 1.0350x faster json-stringify-tinderbox 29.408+-1.629 ? 30.660+-3.014 ? might be 1.0426x slower stanford-crypto-aes 58.172+-1.052 ? 58.742+-0.423 ? stanford-crypto-ccm 49.042+-1.354 47.664+-0.995 might be 1.0289x faster stanford-crypto-pbkdf2 111.586+-3.286 109.668+-1.530 might be 1.0175x faster stanford-crypto-sha256-iterative 43.277+-1.208 ? 44.232+-2.329 ? might be 1.0221x slower <arithmetic> 87.614+-1.126 ^ 85.312+-0.594 ^ definitely 1.0270x faster TipOfTree ABC JSRegress: abc-forward-loop-equal 75.3774+-3.5549 ^ 47.8453+-1.5054 ^ definitely 1.5754x faster abc-postfix-backward-loop 74.1728+-2.1592 ^ 47.3682+-1.3506 ^ definitely 1.5659x faster abc-simple-backward-loop 72.4122+-1.5056 ^ 47.1067+-1.3252 ^ definitely 1.5372x faster abc-simple-forward-loop 73.6608+-2.7843 ^ 47.4704+-1.5804 ^ definitely 1.5517x faster abs-boolean 2.8088+-0.3358 2.7163+-0.0870 might be 1.0341x faster adapt-to-double-divide 16.8056+-0.5408 16.6285+-0.1994 might be 1.0106x faster aliased-arguments-getbyval 1.4012+-0.2125 1.3156+-0.0592 might be 1.0650x faster allocate-big-object 2.9568+-0.1464 ? 2.9953+-0.1636 ? might be 1.0130x slower arguments-named-and-reflective 12.4707+-0.2785 ? 13.2434+-0.9065 ? might be 1.0620x slower arguments-out-of-bounds 14.7793+-0.7089 14.7371+-0.6646 arguments-strict-mode 10.9108+-1.0062 ? 11.3059+-0.9263 ? might be 1.0362x slower arguments 10.1280+-1.0863 ? 10.6556+-0.8521 ? might be 1.0521x slower arity-mismatch-inlining 0.8606+-0.0197 ? 0.9046+-0.0631 ? might be 1.0512x slower array-access-polymorphic-structure 7.3223+-0.9251 ? 7.3725+-0.9116 ? array-nonarray-polymorhpic-access 33.0256+-0.8787 32.6584+-0.8839 might be 1.0112x faster array-prototype-every 85.8985+-2.9017 ? 88.7367+-3.5504 ? might be 1.0330x slower array-prototype-forEach 83.2795+-3.3836 ? 84.7211+-2.6273 ? might be 1.0173x slower array-prototype-map 94.6956+-5.6371 92.2486+-2.3710 might be 1.0265x faster array-prototype-reduce 81.0990+-2.0881 ? 82.4751+-1.5355 ? might be 1.0170x slower array-prototype-reduceRight 81.7428+-2.5749 ? 82.4523+-3.3261 ? array-prototype-some 85.4868+-4.3089 ? 88.6150+-2.9410 ? might be 1.0366x slower array-splice-contiguous 41.3377+-1.5385 ? 42.7027+-1.7323 ? might be 1.0330x slower array-with-double-add 4.5020+-0.3640 4.4332+-0.4273 might be 1.0155x faster array-with-double-increment 3.4929+-0.2670 3.2608+-0.0276 might be 1.0712x faster array-with-double-mul-add 5.2268+-0.1595 ? 5.2456+-0.0956 ? array-with-double-sum 3.7229+-0.6865 3.3477+-0.0585 might be 1.1121x faster array-with-int32-add-sub 6.9163+-0.0870 6.8372+-0.0874 might be 1.0116x faster array-with-int32-or-double-sum 3.4281+-0.0667 3.3877+-0.0605 might be 1.0119x faster ArrayBuffer-DataView-alloc-large-long-lived 37.1376+-1.4109 ? 38.5622+-2.8303 ? might be 1.0384x slower ArrayBuffer-DataView-alloc-long-lived 15.1954+-1.5141 ? 15.6905+-1.9657 ? might be 1.0326x slower ArrayBuffer-Int32Array-byteOffset 3.8742+-0.3285 ? 4.1673+-0.4446 ? might be 1.0757x slower ArrayBuffer-Int8Array-alloc-large-long-lived 38.4498+-1.1179 ? 40.0710+-2.4725 ? might be 1.0422x slower ArrayBuffer-Int8Array-alloc-long-lived-buffer 24.0767+-2.0528 23.2297+-2.3103 might be 1.0365x faster ArrayBuffer-Int8Array-alloc-long-lived 13.7183+-0.3784 ? 14.1246+-1.4691 ? might be 1.0296x slower ArrayBuffer-Int8Array-alloc 10.7337+-0.2665 ? 11.5194+-1.8108 ? might be 1.0732x slower asmjs_bool_bug 7.8251+-0.2019 7.7767+-0.2162 assign-custom-setter-polymorphic 3.3092+-0.0822 3.2386+-0.3639 might be 1.0218x faster assign-custom-setter 5.0907+-0.8878 4.3376+-0.3387 might be 1.1736x faster basic-set 9.6776+-0.6905 9.5453+-0.2849 might be 1.0139x faster big-int-mul 4.5255+-0.3373 ^ 4.0625+-0.0654 ^ definitely 1.1140x faster boolean-test 3.2496+-0.3687 ? 3.3581+-0.2122 ? might be 1.0334x slower branch-fold 4.2360+-0.4902 4.0019+-0.1961 might be 1.0585x faster branch-on-string-as-boolean 20.5280+-0.5171 ? 22.4296+-1.6887 ? might be 1.0926x slower by-val-generic 8.5166+-0.3107 8.5102+-0.2323 call-spread-apply 30.5061+-1.3819 30.3291+-1.6474 call-spread-call 26.6980+-1.6376 25.4113+-0.6864 might be 1.0506x faster captured-assignments 0.5507+-0.0542 ? 0.5601+-0.0631 ? might be 1.0171x slower cast-int-to-double 5.3283+-0.0608 5.3105+-0.0366 cell-argument 8.6000+-0.2663 ? 8.7522+-0.2699 ? might be 1.0177x slower cfg-simplify 2.9813+-0.3132 2.9375+-0.1878 might be 1.0149x faster chain-getter-access 9.7462+-0.8438 9.4107+-0.2031 might be 1.0356x faster cmpeq-obj-to-obj-other 12.6137+-0.3902 11.8312+-0.4621 might be 1.0661x faster constant-test 5.0288+-0.0281 ? 5.2840+-0.7559 ? might be 1.0507x slower create-lots-of-functions 11.7549+-0.3196 ? 11.8339+-0.5868 ? cse-new-array-buffer 2.5860+-0.1168 ? 2.6790+-0.2678 ? might be 1.0360x slower cse-new-array 2.6932+-0.1243 ? 2.6988+-0.1029 ? DataView-custom-properties 43.8945+-1.8256 42.8975+-1.4967 might be 1.0232x faster deconstructing-parameters-overridden-by-function 0.5804+-0.0283 ? 0.6008+-0.0934 ? might be 1.0351x slower delay-tear-off-arguments-strictmode 14.7775+-0.5230 14.2266+-0.2785 might be 1.0387x faster deltablue-varargs 247.5038+-2.2917 ? 249.2660+-2.4610 ? destructuring-arguments 17.3858+-0.4469 ? 17.6112+-0.9052 ? might be 1.0130x slower destructuring-swap 5.4111+-0.4472 5.1683+-0.1447 might be 1.0470x faster direct-arguments-getbyval 1.4550+-0.2212 1.3228+-0.0847 might be 1.0999x faster div-boolean-double 5.3105+-0.1151 ? 5.3567+-0.1668 ? div-boolean 8.0617+-0.3088 7.9350+-0.1601 might be 1.0160x faster double-get-by-val-out-of-bounds 4.7452+-0.2525 4.5974+-0.0461 might be 1.0322x faster double-pollution-getbyval 8.9469+-0.0641 ? 9.0156+-0.2396 ? double-pollution-putbyoffset 4.4755+-0.1257 ? 4.4887+-0.1962 ? double-real-use 29.9420+-0.6770 ? 31.5201+-1.7683 ? might be 1.0527x slower double-to-int32-typed-array-no-inline 2.6657+-0.1737 2.4150+-0.1649 might be 1.1038x faster double-to-int32-typed-array 2.0288+-0.1556 ? 2.0494+-0.1775 ? might be 1.0102x slower double-to-uint32-typed-array-no-inline 2.6318+-0.1879 ? 2.8346+-0.2313 ? might be 1.0771x slower double-to-uint32-typed-array 2.2504+-0.3760 ? 2.2588+-0.4819 ? elidable-new-object-dag 44.3819+-1.7523 43.7157+-2.1059 might be 1.0152x faster elidable-new-object-roflcopter 44.7461+-0.9156 ? 45.5520+-1.3921 ? might be 1.0180x slower elidable-new-object-then-call 40.2166+-1.5685 ? 40.3070+-1.6023 ? elidable-new-object-tree 46.4867+-0.7588 45.6503+-0.8967 might be 1.0183x faster empty-string-plus-int 5.7586+-0.2323 5.5883+-0.1708 might be 1.0305x faster emscripten-cube2hash 38.3882+-1.6519 ? 39.0316+-1.1717 ? might be 1.0168x slower exit-length-on-plain-object 14.2195+-0.5448 ? 14.9981+-1.2581 ? might be 1.0548x slower external-arguments-getbyval 1.3781+-0.0848 1.2575+-0.0780 might be 1.0959x faster external-arguments-putbyval 2.4806+-0.1078 2.4443+-0.1261 might be 1.0148x faster fixed-typed-array-storage-var-index 1.2923+-0.0251 1.2537+-0.0822 might be 1.0308x faster fixed-typed-array-storage 0.9991+-0.1257 ? 1.0522+-0.2782 ? might be 1.0532x slower Float32Array-matrix-mult 4.6896+-0.2206 ? 4.9040+-0.7689 ? might be 1.0457x slower Float32Array-to-Float64Array-set 56.7085+-1.1478 ^ 53.0980+-1.5046 ^ definitely 1.0680x faster Float64Array-alloc-long-lived 88.6842+-1.7099 88.0547+-1.2654 Float64Array-to-Int16Array-set 69.9187+-1.3835 ? 71.1616+-0.3354 ? might be 1.0178x slower fold-double-to-int 13.9430+-0.5594 13.9371+-0.7076 fold-get-by-id-to-multi-get-by-offset-rare-int 11.0474+-1.4521 10.7326+-0.8661 might be 1.0293x faster fold-get-by-id-to-multi-get-by-offset 10.7014+-1.1219 ? 10.7251+-1.2815 ? fold-multi-get-by-offset-to-get-by-offset 9.0004+-1.5619 ? 9.7424+-1.1130 ? might be 1.0824x slower fold-multi-get-by-offset-to-poly-get-by-offset 8.7856+-0.6613 ? 8.8689+-1.2596 ? fold-multi-put-by-offset-to-poly-put-by-offset 9.9988+-0.7373 9.6727+-1.1343 might be 1.0337x faster fold-multi-put-by-offset-to-put-by-offset 7.5928+-0.5480 ? 7.6893+-1.1035 ? might be 1.0127x slower fold-multi-put-by-offset-to-replace-or-transition-put-by-offset 9.9873+-0.3813 ? 10.0739+-0.3975 ? fold-put-by-id-to-multi-put-by-offset 10.3665+-1.4604 ? 10.5044+-1.2599 ? might be 1.0133x slower fold-put-structure 8.2544+-0.6664 7.3497+-1.4782 might be 1.1231x faster for-of-iterate-array-entries 4.7482+-0.2403 4.7017+-0.2235 for-of-iterate-array-keys 3.7830+-0.1125 ? 4.1432+-0.4748 ? might be 1.0952x slower for-of-iterate-array-values 3.7236+-0.3282 3.6718+-0.2302 might be 1.0141x faster fround 21.5612+-0.7981 21.5582+-0.5902 ftl-library-inlining-dataview 65.2191+-1.8325 ? 66.5548+-3.6585 ? might be 1.0205x slower ftl-library-inlining 66.7288+-0.2653 ? 75.5047+-18.4948 ? might be 1.1315x slower function-dot-apply 2.5102+-0.4472 2.3799+-0.2682 might be 1.0547x faster function-test 2.9355+-0.0207 ? 3.0136+-0.1607 ? might be 1.0266x slower function-with-eval 105.4561+-4.3288 ? 106.7240+-4.3207 ? might be 1.0120x slower gcse-poly-get-less-obvious 19.2033+-0.9650 18.8009+-0.4517 might be 1.0214x faster gcse-poly-get 20.4542+-1.2201 19.7128+-0.8873 might be 1.0376x faster gcse 4.4358+-0.0850 4.3538+-0.0527 might be 1.0188x faster get-by-id-bimorphic-check-structure-elimination-simple 2.8761+-0.2561 2.8062+-0.0856 might be 1.0249x faster get-by-id-bimorphic-check-structure-elimination 6.0948+-0.1446 ? 6.1870+-0.1959 ? might be 1.0151x slower get-by-id-chain-from-try-block 6.9343+-0.7729 6.5419+-0.0758 might be 1.0600x faster get-by-id-check-structure-elimination 5.4994+-0.5786 5.2740+-0.2191 might be 1.0427x faster get-by-id-proto-or-self 18.9292+-1.0148 ? 19.0758+-1.8601 ? get-by-id-quadmorphic-check-structure-elimination-simple 2.9965+-0.0570 ? 3.1601+-0.1453 ? might be 1.0546x slower get-by-id-self-or-proto 19.1013+-2.0658 ? 19.4988+-1.8638 ? might be 1.0208x slower get-by-val-out-of-bounds 4.5004+-0.1437 ? 4.5832+-0.2495 ? might be 1.0184x slower get_callee_monomorphic 3.2618+-0.7912 2.9971+-0.2376 might be 1.0883x faster get_callee_polymorphic 3.8188+-0.1670 ? 3.9092+-0.3501 ? might be 1.0237x slower getter-no-activation 5.3545+-0.4195 5.2229+-0.3908 might be 1.0252x faster getter-prototype 15.6335+-0.6049 15.3507+-0.9126 might be 1.0184x faster getter-richards 134.7804+-7.3646 132.6525+-5.7563 might be 1.0160x faster getter 6.3554+-0.9512 6.0685+-0.6731 might be 1.0473x faster global-var-const-infer-fire-from-opt 0.9745+-0.0647 ? 0.9844+-0.1082 ? might be 1.0101x slower global-var-const-infer 0.9770+-0.2057 ? 1.0829+-0.2418 ? might be 1.1084x slower HashMap-put-get-iterate-keys 31.8450+-2.1292 31.3839+-2.3621 might be 1.0147x faster HashMap-put-get-iterate 34.3000+-3.1986 31.1834+-2.2528 might be 1.0999x faster HashMap-string-put-get-iterate 33.2100+-0.9256 ? 33.6555+-0.7665 ? might be 1.0134x slower hoist-make-rope 12.2407+-1.2655 ? 12.7043+-1.3905 ? might be 1.0379x slower hoist-poly-check-structure-effectful-loop 5.1443+-0.0938 ? 5.2280+-0.1729 ? might be 1.0163x slower hoist-poly-check-structure 3.8209+-0.1111 ? 3.8539+-0.2640 ? imul-double-only 8.8237+-0.5224 ? 9.9184+-1.3223 ? might be 1.1241x slower imul-int-only 9.9987+-0.2673 9.8683+-0.0766 might be 1.0132x faster imul-mixed 8.3538+-0.3140 ? 9.6095+-2.5970 ? might be 1.1503x slower in-four-cases 22.4460+-0.4560 22.2763+-0.2597 in-one-case-false 11.1415+-0.1228 ? 11.3938+-0.3908 ? might be 1.0226x slower in-one-case-true 11.0500+-0.0853 ? 11.5031+-0.6740 ? might be 1.0410x slower in-two-cases 11.7533+-0.3227 11.6383+-0.0671 indexed-properties-in-objects 3.0313+-0.1268 2.9819+-0.0988 might be 1.0166x faster infer-closure-const-then-mov-no-inline 4.5965+-0.7448 3.9635+-0.0609 might be 1.1597x faster infer-closure-const-then-mov 20.0339+-0.3590 19.7205+-0.2441 might be 1.0159x faster infer-closure-const-then-put-to-scope-no-inline 13.0111+-0.6656 12.9114+-0.4654 infer-closure-const-then-put-to-scope 21.5252+-0.5158 ? 21.9180+-1.0052 ? might be 1.0182x slower infer-closure-const-then-reenter-no-inline 55.0421+-0.9203 54.2729+-1.1233 might be 1.0142x faster infer-closure-const-then-reenter 22.6346+-1.0429 22.3550+-0.6938 might be 1.0125x faster infer-constant-global-property 3.6468+-0.1388 3.6075+-0.1222 might be 1.0109x faster infer-constant-property 2.9751+-0.4164 2.9200+-0.3513 might be 1.0189x faster infer-one-time-closure-ten-vars 12.8461+-0.7024 ? 13.2059+-1.0415 ? might be 1.0280x slower infer-one-time-closure-two-vars 12.7457+-1.4275 ? 12.9932+-1.3159 ? might be 1.0194x slower infer-one-time-closure 12.4598+-0.6661 ? 13.4301+-1.6650 ? might be 1.0779x slower infer-one-time-deep-closure 21.7930+-1.4343 21.5463+-1.1718 might be 1.0114x faster inline-arguments-access 5.0683+-0.4439 4.7666+-0.1743 might be 1.0633x faster inline-arguments-aliased-access 4.7885+-0.3912 4.6746+-0.1380 might be 1.0243x faster inline-arguments-local-escape 4.6592+-0.0499 ? 4.6850+-0.0696 ? inline-get-scoped-var 4.8912+-0.1390 ? 4.8951+-0.1528 ? inlined-put-by-id-transition 12.4661+-0.5212 12.2018+-1.0271 might be 1.0217x faster int-or-other-abs-then-get-by-val 5.0776+-0.0776 5.0597+-0.1409 int-or-other-abs-zero-then-get-by-val 17.5265+-0.2930 ? 17.7052+-0.8847 ? might be 1.0102x slower int-or-other-add-then-get-by-val 4.4357+-0.1547 4.3669+-0.0226 might be 1.0157x faster int-or-other-add 5.5638+-0.2037 ? 5.6377+-0.4717 ? might be 1.0133x slower int-or-other-div-then-get-by-val 4.3710+-0.1106 4.3343+-0.1779 int-or-other-max-then-get-by-val 4.5190+-0.2978 4.5103+-0.3118 int-or-other-min-then-get-by-val 4.3526+-0.0266 ? 4.4343+-0.1739 ? might be 1.0188x slower int-or-other-mod-then-get-by-val 3.9632+-0.0387 ? 4.0865+-0.2168 ? might be 1.0311x slower int-or-other-mul-then-get-by-val 4.0070+-0.0706 ? 4.1124+-0.3533 ? might be 1.0263x slower int-or-other-neg-then-get-by-val 4.9795+-0.4141 4.8464+-0.0740 might be 1.0275x faster int-or-other-neg-zero-then-get-by-val 18.4338+-1.4504 ? 20.2390+-4.2630 ? might be 1.0979x slower int-or-other-sub-then-get-by-val 4.4826+-0.1827 ? 4.5574+-0.4279 ? might be 1.0167x slower int-or-other-sub 3.8208+-0.3274 3.6892+-0.1406 might be 1.0357x faster int-overflow-local 4.5694+-0.0332 ? 4.5916+-0.0389 ? Int16Array-alloc-long-lived 52.7960+-0.9886 ? 53.1394+-1.7736 ? Int16Array-bubble-sort-with-byteLength 20.5752+-1.5240 20.5035+-0.9296 Int16Array-bubble-sort 20.9473+-0.9913 20.8058+-1.3404 Int16Array-load-int-mul 1.6203+-0.1864 1.5389+-0.0537 might be 1.0529x faster Int16Array-to-Int32Array-set 56.7273+-1.8823 56.1931+-1.5213 Int32Array-alloc-large 24.8308+-1.7008 24.4211+-0.7459 might be 1.0168x faster Int32Array-alloc-long-lived 63.4379+-1.1433 ? 64.0446+-0.6727 ? Int32Array-alloc 3.6144+-0.3962 ? 3.6787+-0.5701 ? might be 1.0178x slower Int32Array-Int8Array-view-alloc 7.1302+-0.8118 6.7197+-0.3091 might be 1.0611x faster int52-spill 5.6859+-0.1007 ? 5.7664+-0.0734 ? might be 1.0141x slower Int8Array-alloc-long-lived 49.1965+-2.2792 48.9821+-2.0092 Int8Array-load-with-byteLength 3.6831+-0.3908 3.4236+-0.0404 might be 1.0758x faster Int8Array-load 3.5141+-0.1522 ? 3.6687+-0.3961 ? might be 1.0440x slower integer-divide 11.2480+-0.3004 11.0696+-0.3717 might be 1.0161x faster integer-modulo 2.2475+-0.2738 2.1560+-0.0929 might be 1.0424x faster is-boolean-fold-tricky 4.4791+-0.0884 ? 4.4986+-0.0414 ? is-boolean-fold 2.9380+-0.1221 2.9000+-0.1478 might be 1.0131x faster is-function-fold-tricky-internal-function 12.0419+-0.1709 ? 12.7079+-1.2483 ? might be 1.0553x slower is-function-fold-tricky 4.9500+-0.4911 4.5997+-0.0830 might be 1.0762x faster is-function-fold 3.0971+-0.3009 3.0736+-0.3746 is-number-fold-tricky 4.5676+-0.2181 ? 4.6206+-0.1304 ? might be 1.0116x slower is-number-fold 2.9073+-0.0385 2.9053+-0.1224 is-object-or-null-fold-functions 3.1860+-0.3112 3.0857+-0.3883 might be 1.0325x faster is-object-or-null-fold-less-tricky 4.5764+-0.1650 ? 4.8550+-0.4270 ? might be 1.0609x slower is-object-or-null-fold-tricky 6.6755+-0.0641 ? 6.6937+-0.1089 ? is-object-or-null-fold 2.9935+-0.1090 2.8755+-0.0283 might be 1.0410x faster is-object-or-null-trickier-function 4.6710+-0.1520 ? 5.0263+-0.4400 ? might be 1.0761x slower is-object-or-null-trickier-internal-function 12.7232+-0.3713 ? 13.7996+-1.7587 ? might be 1.0846x slower is-object-or-null-tricky-function 4.7909+-0.3689 4.7909+-0.2309 is-object-or-null-tricky-internal-function 9.5022+-0.2475 ? 9.7397+-0.7677 ? might be 1.0250x slower is-string-fold-tricky 4.5712+-0.2380 ? 4.6450+-0.2204 ? might be 1.0161x slower is-string-fold 3.0743+-0.3203 2.8646+-0.0810 might be 1.0732x faster is-undefined-fold-tricky 3.8168+-0.0926 ? 3.8989+-0.2098 ? might be 1.0215x slower is-undefined-fold 3.0251+-0.3697 ? 3.0463+-0.3585 ? large-int-captured 4.8487+-0.1050 ? 4.9942+-0.2301 ? might be 1.0300x slower large-int-neg 16.9314+-1.2634 16.8657+-0.7946 large-int 16.4041+-2.6050 15.3085+-1.6129 might be 1.0716x faster load-varargs-elimination 23.2752+-0.4936 ? 24.1651+-1.9781 ? might be 1.0382x slower logical-not-weird-types 3.3204+-0.0998 ? 3.4236+-0.1848 ? might be 1.0311x slower logical-not 5.2036+-1.3052 4.6563+-0.0516 might be 1.1175x faster lots-of-fields 12.2292+-0.2119 ? 12.3655+-0.1011 ? might be 1.0111x slower make-indexed-storage 3.2586+-0.4297 ? 3.3129+-0.3744 ? might be 1.0166x slower make-rope-cse 12.4507+-1.1125 ? 13.2835+-1.3802 ? might be 1.0669x slower marsaglia-larger-ints 36.4821+-0.8588 ? 38.3978+-2.4731 ? might be 1.0525x slower marsaglia-osr-entry 23.9025+-1.6352 23.3490+-0.4819 might be 1.0237x faster math-with-out-of-bounds-array-values 24.9624+-0.6751 23.9163+-0.6323 might be 1.0437x faster max-boolean 2.5660+-0.0633 2.5124+-0.0471 might be 1.0213x faster method-on-number 18.2350+-0.7152 17.6905+-0.4468 might be 1.0308x faster min-boolean 2.7280+-0.2994 2.5045+-0.0238 might be 1.0893x faster minus-boolean-double 3.2909+-0.1450 3.2832+-0.0919 minus-boolean 2.4595+-0.1252 ? 2.5841+-0.4671 ? might be 1.0507x slower misc-strict-eq 39.6392+-0.9747 38.3512+-1.1700 might be 1.0336x faster mod-boolean-double 11.0216+-0.1970 10.9122+-0.1312 might be 1.0100x faster mod-boolean 7.8948+-0.0826 ? 7.9404+-0.1432 ? mul-boolean-double 3.8795+-0.2749 3.8170+-0.1536 might be 1.0164x faster mul-boolean 3.2009+-0.4307 3.1224+-0.3546 might be 1.0251x faster neg-boolean 3.3785+-0.2586 3.1917+-0.0273 might be 1.0585x faster negative-zero-divide 0.4061+-0.0425 ? 0.4112+-0.0277 ? might be 1.0125x slower negative-zero-modulo 0.4082+-0.0460 0.4080+-0.0438 negative-zero-negate 0.3873+-0.0604 ? 0.4148+-0.0935 ? might be 1.0710x slower nested-function-parsing 41.8825+-2.8926 40.3062+-1.4413 might be 1.0391x faster new-array-buffer-dead 112.6071+-1.3509 111.8824+-3.0027 new-array-buffer-push 7.6626+-1.0624 7.0334+-0.2359 might be 1.0894x faster new-array-dead 19.6606+-1.5469 19.5090+-0.3781 new-array-push 7.3515+-1.3677 6.6348+-0.2392 might be 1.1080x faster no-inline-constructor 41.2630+-1.8830 40.7146+-1.3859 might be 1.0135x faster number-test 3.1208+-0.0732 ? 3.1703+-0.1508 ? might be 1.0159x slower object-closure-call 5.7198+-0.0303 5.7119+-0.0160 object-test 2.9261+-0.0518 2.9216+-0.1427 obvious-sink-pathology-taken 144.3696+-4.7926 143.7350+-3.9397 obvious-sink-pathology 132.7749+-2.1093 ? 133.3378+-2.7050 ? obviously-elidable-new-object 36.2891+-1.3717 35.5871+-1.4511 might be 1.0197x faster plus-boolean-arith 2.5822+-0.0407 ? 2.6537+-0.3269 ? might be 1.0277x slower plus-boolean-double 3.3415+-0.2132 ? 3.3597+-0.2834 ? plus-boolean 2.5417+-0.1103 ? 2.6486+-0.3213 ? might be 1.0421x slower poly-chain-access-different-prototypes-simple 3.3324+-0.0858 ? 3.3440+-0.0442 ? poly-chain-access-different-prototypes 2.8354+-0.3366 2.6584+-0.2363 might be 1.0666x faster poly-chain-access-simpler 3.4448+-0.1197 ? 3.5417+-0.4013 ? might be 1.0281x slower poly-chain-access 2.5884+-0.0158 ? 2.7445+-0.1596 ? might be 1.0603x slower poly-stricteq 61.1344+-2.1780 59.8724+-1.8982 might be 1.0211x faster polymorphic-array-call 1.4302+-0.0862 1.3976+-0.0614 might be 1.0233x faster polymorphic-get-by-id 3.3131+-0.1801 3.1737+-0.0339 might be 1.0439x faster polymorphic-put-by-id 33.9239+-2.4388 32.2137+-1.9043 might be 1.0531x faster polymorphic-structure 15.6589+-0.9997 15.2581+-0.7475 might be 1.0263x faster polyvariant-monomorphic-get-by-id 8.6306+-0.1167 ? 8.6667+-0.1263 ? proto-getter-access 9.5922+-0.2585 9.3617+-0.2046 might be 1.0246x faster put-by-id-replace-and-transition 9.7788+-0.2816 9.6748+-0.1837 might be 1.0107x faster put-by-id-slightly-polymorphic 2.9264+-0.1416 2.9131+-0.1131 put-by-id 12.8243+-0.3458 ? 12.9011+-0.3184 ? put-by-val-direct 0.4140+-0.0390 ? 0.4235+-0.0464 ? might be 1.0231x slower put-by-val-large-index-blank-indexing-type 12.7731+-1.0667 12.5999+-1.2844 might be 1.0137x faster put-by-val-machine-int 2.9362+-0.1228 ? 3.0000+-0.3390 ? might be 1.0218x slower rare-osr-exit-on-local 15.1906+-0.4196 ? 15.3474+-0.4517 ? might be 1.0103x slower register-pressure-from-osr 4.6191+-0.2874 4.4557+-0.0595 might be 1.0367x faster repeat-multi-get-by-offset 24.6261+-0.3345 ? 24.8691+-0.4813 ? setter-prototype 10.5738+-0.2913 ? 10.5950+-0.1918 ? setter 6.5992+-0.9045 6.3722+-0.8996 might be 1.0356x faster simple-activation-demo 25.3594+-1.1114 ? 25.9238+-1.3836 ? might be 1.0223x slower simple-getter-access 12.2277+-1.2798 11.8415+-0.2083 might be 1.0326x faster simple-poly-call-nested 8.2623+-0.2577 ? 8.3722+-0.7670 ? might be 1.0133x slower simple-poly-call 1.3537+-0.0860 1.3367+-0.0391 might be 1.0127x faster sin-boolean 23.9644+-1.5071 23.1274+-0.8079 might be 1.0362x faster singleton-scope 63.3407+-2.4090 63.1540+-1.9670 sink-function 12.4911+-0.3329 ? 12.8576+-0.7769 ? might be 1.0293x slower sink-huge-activation 19.1983+-0.9434 ? 19.2520+-0.6571 ? sinkable-new-object-dag 72.9355+-6.8371 71.2257+-0.8491 might be 1.0240x faster sinkable-new-object-taken 51.1085+-2.8746 ? 56.7357+-3.7854 ? might be 1.1101x slower sinkable-new-object 39.6759+-2.2480 ? 40.5074+-1.4712 ? might be 1.0210x slower slow-array-profile-convergence 3.2616+-0.4616 3.1048+-0.3721 might be 1.0505x faster slow-convergence 3.9661+-0.5547 3.7228+-0.1287 might be 1.0654x faster slow-ternaries 20.7852+-2.8173 ? 22.1277+-1.9560 ? might be 1.0646x slower sorting-benchmark 19.4729+-0.6396 19.4694+-0.9927 sparse-conditional 1.2331+-0.1530 ? 1.2562+-0.0984 ? might be 1.0187x slower splice-to-remove 16.1715+-1.4076 16.0125+-1.3640 string-char-code-at 16.2834+-0.1868 ? 17.1071+-1.2629 ? might be 1.0506x slower string-concat-object 2.8222+-0.3954 2.6672+-0.1803 might be 1.0581x faster string-concat-pair-object 2.7474+-0.2342 ? 2.7651+-0.3132 ? string-concat-pair-simple 12.6751+-1.2947 11.8915+-0.3924 might be 1.0659x faster string-concat-simple 12.6304+-1.0515 12.2992+-0.8564 might be 1.0269x faster string-cons-repeat 8.7845+-0.6525 8.0080+-0.2733 might be 1.0970x faster string-cons-tower 8.9521+-0.8767 8.3886+-0.5596 might be 1.0672x faster string-equality 18.3380+-1.2367 ? 18.4195+-0.8158 ? string-get-by-val-big-char 7.4319+-0.5637 7.2170+-0.0610 might be 1.0298x faster string-get-by-val-out-of-bounds-insane 3.6762+-0.1125 ? 3.9624+-0.4809 ? might be 1.0779x slower string-get-by-val-out-of-bounds 5.5040+-0.0419 ? 5.9184+-0.6679 ? might be 1.0753x slower string-get-by-val 3.4622+-0.0394 ? 3.6123+-0.3683 ? might be 1.0434x slower string-hash 2.2345+-0.2178 2.0970+-0.1102 might be 1.0656x faster string-long-ident-equality 14.5144+-0.1500 ? 14.8630+-0.4418 ? might be 1.0240x slower string-out-of-bounds 14.9540+-0.2555 ? 15.5554+-0.8906 ? might be 1.0402x slower string-repeat-arith 34.2933+-1.3669 33.7427+-2.4550 might be 1.0163x faster string-sub 68.4407+-4.3276 66.3802+-2.7317 might be 1.0310x faster string-test 3.0449+-0.1047 ? 3.1334+-0.2613 ? might be 1.0291x slower string-var-equality 34.3935+-1.8177 32.4599+-0.6365 might be 1.0596x faster structure-hoist-over-transitions 2.8082+-0.1454 2.7729+-0.1855 might be 1.0127x faster substring-concat-weird 44.0647+-6.1500 41.0913+-2.1720 might be 1.0724x faster substring-concat 43.3745+-1.3007 42.5035+-0.8560 might be 1.0205x faster substring 46.6376+-1.7047 ? 46.9411+-2.8114 ? switch-char-constant 2.8822+-0.1340 ? 2.8887+-0.1465 ? switch-char 7.2725+-0.9559 7.0166+-0.8063 might be 1.0365x faster switch-constant 8.5747+-0.3210 ? 8.6440+-0.4173 ? switch-string-basic-big-var 18.7152+-0.5142 18.4188+-0.3750 might be 1.0161x faster switch-string-basic-big 15.0127+-0.3717 ? 15.0696+-0.6601 ? switch-string-basic-var 15.7190+-0.9958 15.6875+-1.2207 switch-string-basic 13.7335+-0.2325 13.6605+-0.2100 switch-string-big-length-tower-var 20.7775+-1.3132 ? 21.1073+-1.3631 ? might be 1.0159x slower switch-string-length-tower-var 15.9058+-0.9173 15.6562+-0.3901 might be 1.0159x faster switch-string-length-tower 13.3571+-0.4115 13.3369+-0.4185 switch-string-short 13.0681+-0.2632 ? 13.0780+-0.2410 ? switch 12.6971+-0.3522 ? 12.8331+-0.3766 ? might be 1.0107x slower tear-off-arguments-simple 3.7163+-0.2779 3.5373+-0.1716 might be 1.0506x faster tear-off-arguments 4.8767+-0.0937 4.8663+-0.0628 temporal-structure 12.3037+-0.0991 12.1988+-0.2099 to-int32-boolean 14.0151+-0.2238 ? 14.1297+-0.1866 ? try-catch-get-by-val-cloned-arguments 15.9945+-1.4572 15.0421+-0.8063 might be 1.0633x faster try-catch-get-by-val-direct-arguments 6.8995+-0.9062 6.6646+-0.3664 might be 1.0353x faster try-catch-get-by-val-scoped-arguments 8.1883+-0.2582 ? 9.2985+-1.5091 ? might be 1.1356x slower typed-array-get-set-by-val-profiling 33.1230+-0.7783 ^ 28.0772+-0.4511 ^ definitely 1.1797x faster undefined-property-access 349.7361+-12.9536 342.1995+-2.0816 might be 1.0220x faster undefined-test 3.0733+-0.0326 ? 3.1207+-0.0918 ? might be 1.0154x slower unprofiled-licm 22.9499+-0.4767 ? 23.1497+-0.5466 ? varargs-call 15.0807+-0.2281 ? 15.3544+-0.8418 ? might be 1.0182x slower varargs-construct-inline 29.3266+-1.3538 28.2580+-0.9663 might be 1.0378x faster varargs-construct 23.5056+-1.5459 22.6628+-0.5438 might be 1.0372x faster varargs-inline 9.4643+-0.2805 9.3975+-0.0842 varargs-strict-mode 9.9999+-0.0709 ? 10.2587+-0.3611 ? might be 1.0259x slower varargs 10.5316+-1.1253 ? 11.3717+-3.5850 ? might be 1.0798x slower weird-inlining-const-prop 3.2692+-0.2131 ? 3.3594+-0.2584 ? might be 1.0276x slower <geometric> 9.2010+-0.0166 ^ 9.1231+-0.0308 ^ definitely 1.0085x faster TipOfTree ABC AsmBench: bigfib.cpp 501.2403+-2.0450 501.0593+-1.5281 cray.c 427.7279+-1.4031 ! 430.2067+-1.0034 ! definitely 1.0058x slower dry.c 488.7017+-11.9086 ? 493.8884+-1.8162 ? might be 1.0106x slower FloatMM.c 735.0844+-33.3353 722.1065+-1.5561 might be 1.0180x faster gcc-loops.cpp 4097.9397+-15.9951 ? 4111.0414+-14.6130 ? n-body.c 972.7664+-1.4076 ? 976.3195+-2.2343 ? Quicksort.c 425.8973+-11.4986 ? 435.4954+-30.1243 ? might be 1.0225x slower stepanov_container.cpp 3597.7916+-16.2538 ? 3875.1390+-453.6387 ? might be 1.0771x slower Towers.c 245.5719+-1.6510 244.3245+-3.9464 <geometric> 786.6779+-4.1868 ? 794.7784+-15.2882 ? might be 1.0103x slower TipOfTree ABC CompressionBench: huffman 379.7402+-15.6657 ^ 357.2908+-3.5455 ^ definitely 1.0628x faster arithmetic-simple 375.8312+-3.8905 ^ 347.6770+-1.8509 ^ definitely 1.0810x faster arithmetic-precise 299.9359+-5.9868 294.5298+-2.8183 might be 1.0184x faster arithmetic-complex-precise 300.9635+-13.8135 294.1683+-12.4777 might be 1.0231x faster arithmetic-precise-order-0 388.4006+-3.6318 ^ 363.5165+-4.1081 ^ definitely 1.0685x faster arithmetic-precise-order-1 324.8556+-2.3355 ? 325.7362+-7.4961 ? arithmetic-precise-order-2 361.5630+-3.8288 361.0098+-2.8446 arithmetic-simple-order-1 421.7841+-1.1354 ^ 401.1082+-18.8376 ^ definitely 1.0515x faster arithmetic-simple-order-2 491.2053+-26.6762 ^ 454.6497+-4.0502 ^ definitely 1.0804x faster lz-string 325.8858+-8.6184 320.0770+-3.4284 might be 1.0181x faster <geometric> 362.8556+-2.2259 ^ 348.9970+-0.9225 ^ definitely 1.0397x faster TipOfTree ABC Geomean of preferred means: <scaled-result> 62.8416+-0.5070 62.3828+-0.2250 might be 1.0074x faster
Created attachment 254684 [details] the patch
Attachment 254684 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:313: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:866: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:866: Multi line control clauses should use braces. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1141: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1190: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 5 in 20 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 254684 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=254684&action=review > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:155 > + if (m_offset == std::numeric_limits<int>::min()) > + return Relationship(); It would be good to have a test covering this case. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:309 > + // Make sure that if we have a LessThan, then it's first. > + if (b.m_kind == LessThan) > + std::swap(a, b); > + > + // Make sure that if we have a NotEqual, then it's first. > + if (b.m_kind == NotEqual) > + std::swap(a, b); I would move those to mergeImpl() and remove the comments. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:332 > + Relationship filter(const Relationship& other) const TODO: review this. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:341 > + // this to assume that we different offsets anytime that everything but the offset is "assume that we different offsets anytime" > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:436 > + int minRightValue; > + if (m_right->isInt32Constant()) > + minRightValue = m_right->asInt32(); > + else > + minRightValue = std::numeric_limits<int>::min(); Maybe simpler like this? int minRightValue = std::numeric_limits<int>::min(); if (m_right->isInt32Constant()) minRightValue = m_right->asInt32(); > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:440 > + return clampedSum(minRightValue, m_offset); I am not following this case. If we are here, we have (kind == Equal or kind == NotEqual). Why is the mind value of NotEqual @b + Constant? > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:455 > + int maxRightValue; > + if (m_right->isInt32Constant()) > + maxRightValue = m_right->asInt32(); > + else > + maxRightValue = std::numeric_limits<int>::max(); "Simpler" version here too. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:459 > + return clampedSum(maxRightValue, m_offset); Same question about NotEqual > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:495 > + ASSERT(sameNodesAs(other)); An other precondition is that neither node has the relation "GreaterThan". > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:520 > + // this to assume that we different offsets anytime that everything but the offset is "that we different offsets" > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:531 > + // Saying that you might be B when you've already said that you're anything > + // but A, where A and B are different, is a tautology. You could just say > + // that you're anything but A. Maybe just write an example as this is a pretty obvious case? // Adding "(a == b + 1)" to "(a != b + 5)" has no value. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:548 > + // If we have C > D, then we could keep both claims, but we are cheap, so we > + // don't. We just use the NotEqual. Wouldn't it be easier to implement it instead of justifying not having it? :) > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:611 > + std::max(m_offset, other.m_offset) + 1); Not a fan of the implicit overflow here but it's harmless. It would be good to have tests for those cases though. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:645 > + // Before we do anything, make sure that we have a zero constant at the top. I would also say why in addition to what. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:939 > + if (!node->child2()->isInt32Constant()) No love for (constant + @value)? > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:987 > + if (!sumOverflows<int>(std::numeric_limits<int>::max(), -offset, 1)) { I don't follow this. Say way have: @1 = @x + 1000; @2 = @1 + 10; You add the relationship @1 < 0 + max - 10 + 1. Say that we > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1274 > + 1274 lines! The original CSS JIT was small than that :)
(In reply to comment #13) > Comment on attachment 254684 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=254684&action=review > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:155 > > + if (m_offset == std::numeric_limits<int>::min()) > > + return Relationship(); > > It would be good to have a test covering this case. Good idea! > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:309 > > + // Make sure that if we have a LessThan, then it's first. > > + if (b.m_kind == LessThan) > > + std::swap(a, b); > > + > > + // Make sure that if we have a NotEqual, then it's first. > > + if (b.m_kind == NotEqual) > > + std::swap(a, b); > > I would move those to mergeImpl() and remove the comments. I don't think so - we cannot swap *this and other in mergeImpl(). :-) > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:332 > > + Relationship filter(const Relationship& other) const > > TODO: review this. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:341 > > + // this to assume that we different offsets anytime that everything but the offset is > > "assume that we different offsets anytime" > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:436 > > + int minRightValue; > > + if (m_right->isInt32Constant()) > > + minRightValue = m_right->asInt32(); > > + else > > + minRightValue = std::numeric_limits<int>::min(); > > Maybe simpler like this? > > int minRightValue = std::numeric_limits<int>::min(); > if (m_right->isInt32Constant()) > minRightValue = m_right->asInt32(); That works, too. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:440 > > + return clampedSum(minRightValue, m_offset); > > I am not following this case. > > If we are here, we have (kind == Equal or kind == NotEqual). > Why is the mind value of NotEqual @b + Constant? Ooops. That's a bug. I added NotEqual after writing this code. The case for LessThan, above, which returns std::numeric_limits<int>::min() should also do the same for NotEqual. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:455 > > + int maxRightValue; > > + if (m_right->isInt32Constant()) > > + maxRightValue = m_right->asInt32(); > > + else > > + maxRightValue = std::numeric_limits<int>::max(); > > "Simpler" version here too. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:459 > > + return clampedSum(maxRightValue, m_offset); > > Same question about NotEqual Ditto, bug. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:495 > > + ASSERT(sameNodesAs(other)); > > An other precondition is that neither node has the relation "GreaterThan". True! I should add that assert. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:520 > > + // this to assume that we different offsets anytime that everything but the offset is > > "that we different offsets" > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:531 > > + // Saying that you might be B when you've already said that you're anything > > + // but A, where A and B are different, is a tautology. You could just say > > + // that you're anything but A. > > Maybe just write an example as this is a pretty obvious case? > // Adding "(a == b + 1)" to "(a != b + 5)" has no value. OK. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:548 > > + // If we have C > D, then we could keep both claims, but we are cheap, so we > > + // don't. We just use the NotEqual. > > Wouldn't it be easier to implement it instead of justifying not having it? :) By "cheap" I mean that we are trying to accelerate convergence. Any time that we create more relationships, we create more things to merge, and possibly increase the number of fixpoint iterations. Not implementing something we don't think is valuable is kind of a convergence hack - fewer relationships means less time spent processing relationships. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:611 > > + std::max(m_offset, other.m_offset) + 1); > > Not a fan of the implicit overflow here but it's harmless. > > It would be good to have tests for those cases though. Interesting. I didn't want this overflow. I'll guard this with sumOverflows() or something. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:645 > > + // Before we do anything, make sure that we have a zero constant at the top. > > I would also say why in addition to what. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:939 > > + if (!node->child2()->isInt32Constant()) > > No love for (constant + @value)? See DFGStrenghtReductionPhase.cpp. It canonicalizes constant+@value to @value+constant. This is also why we don't handle @value-constant. It would have been canonicalized to @value+(-constant). > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:987 > > + if (!sumOverflows<int>(std::numeric_limits<int>::max(), -offset, 1)) { > > I don't follow this. > > Say way have: > @1 = @x + 1000; > @2 = @1 + 10; > > You add the relationship @1 < 0 + max - 10 + 1. > > Say that we I'm curious what you were thinking. :-) > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1274 > > + > > 1274 lines! The original CSS JIT was small than that :)
I don't know why bugzilla cut that comment. The full question was: Say way have: @1 = @x + 10; @2 = @1 + 1000; You add the relationship @1 < int_max - 1000 + 1. And @x < int_max - 1000 + 1 + 10; Now the maxValue of @x is less than (int_max - 1000 + 1 + 10) and we could use that to change the ArithMode to Unchecked. What am I missing?
(In reply to comment #15) > I don't know why bugzilla cut that comment. The full question was: > > Say way have: > @1 = @x + 10; > @2 = @1 + 1000; > > You add the relationship > @1 < int_max - 1000 + 1. > And > @x < int_max - 1000 + 1 + 10; > > Now the maxValue of @x is less than (int_max - 1000 + 1 + 10) and we could > use that to change the ArithMode to Unchecked. > > What am I missing? Note that relationships are flow sensitive. When we set a relationship, that relationship holds only *after* that node executes, and cannot be used to strength-reduce the node itself. Now let me see if I follow. When we see: @1 = @x + 10 Then we conclude that @x < int_max - 10 + 1. We also conclude that @1 > int_min + 10 - 1. This doesn't help us remove any checks from this though: @2 = @1 + 1000 Since @1 has no meaningful upper bound, yet. But after this executes, we will know that @1 < int_max - 1000 + 1 and @2 > int_min + 1000 - 1. Because of the other relationships, we will also have: @x + 10 < int_max - 1000 + 1 @x < int_max - 1000 + 1 - 10 @x < int_max - 1010 + 1 Which means that if you later do: ArithAdd(@x, 1010) Then we can remove the overflow check from that node. But it does not mean that we can retroactively remove the checks from the previous nodes, since all of these relationships come into effect after the execution of those nodes.
Comment on attachment 254684 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=254684&action=review Some more comments. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:331 > + // In some cases, it will do something conservative. It's always safe for this to return > + // *this, or to return other. It'll do that sometimes, mainly to accelerate convergence for > + // things that we don't think are important enough to slow down the analysis. This is pretty clear, I think the null case makes things more complicated. It would be good to justify every use of the null return. Otherwise anyone will be afraid to touch this code in the future because they won't know why some cases return null instead of *this. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:352 > + // Useful helper for flipping. This comment does not help enough IMHO. It would be more helpful to say that you only implement check for LessThan and flip the relation when handling GreaterThan. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:384 > + // @a != @b + C > + // @a < @b + D Reading this patch for a while now, I really like those little examples. They help a lot. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:417 > + return Relationship(); I don't know if you have a rationale for this. I am thinking that keeping the LessThan would be valuable. In general I see code dealing mostly with positive numbers. Knowing an upper bound seems more useful on average. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:743 > + Relationship relationship; relationship -> relationshipForTrueCase or something like that? > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:755 > + } else { This could be if (terminal->child1().useKind() == BooleanUse)
> Note that relationships are flow sensitive. When we set a relationship, > that relationship holds only *after* that node executes, and cannot be used > to strength-reduce the node itself. > > Now let me see if I follow. When we see: > > @1 = @x + 10 > > Then we conclude that @x < int_max - 10 + 1. We also conclude that @1 > > int_min + 10 - 1. > > This doesn't help us remove any checks from this though: > > @2 = @1 + 1000 > > Since @1 has no meaningful upper bound, yet. But after this executes, we > will know that @1 < int_max - 1000 + 1 and @2 > int_min + 1000 - 1. Because > of the other relationships, we will also have: > > @x + 10 < int_max - 1000 + 1 > @x < int_max - 1000 + 1 - 10 > @x < int_max - 1010 + 1 > > Which means that if you later do: > > ArithAdd(@x, 1010) > > Then we can remove the overflow check from that node. But it does not mean > that we can retroactively remove the checks from the previous nodes, since > all of these relationships come into effect after the execution of those > nodes. Ok! Somehow I thought the relationship on @x could end up in the relationship at head. Looking back how merging works, that makes a little more sense :)
(In reply to comment #17) > Comment on attachment 254684 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=254684&action=review > > Some more comments. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:331 > > + // In some cases, it will do something conservative. It's always safe for this to return > > + // *this, or to return other. It'll do that sometimes, mainly to accelerate convergence for > > + // things that we don't think are important enough to slow down the analysis. > > This is pretty clear, I think the null case makes things more complicated. > > It would be good to justify every use of the null return. Otherwise anyone > will be afraid to touch this code in the future because they won't know why > some cases return null instead of *this. Null return means: please represent the intersection of the two relationships by explicitly keeping both relationships. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:352 > > + // Useful helper for flipping. > > This comment does not help enough IMHO. It would be more helpful to say that > you only implement check for LessThan and flip the relation when handling > GreaterThan. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:384 > > + // @a != @b + C > > + // @a < @b + D > > Reading this patch for a while now, I really like those little examples. > They help a lot. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:417 > > + return Relationship(); > > I don't know if you have a rationale for this. I am thinking that keeping > the LessThan would be valuable. In general I see code dealing mostly with > positive numbers. Knowing an upper bound seems more useful on average. That's what this is doing. Returning null means that we keep both relationships. This is how we get things like 0 <= @x < array.length. If we returned *this or if we returned *other, we'd only get 0 <= @x or @x < array.length but not both. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:743 > > + Relationship relationship; > > relationship -> relationshipForTrueCase or something like that? Good idea! > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:755 > > + } else { > > This could be if (terminal->child1().useKind() == BooleanUse) It could be, but it doesn't have to be. We could have a FixupPhase decide that a Branch has an UntypedUse edge, but by later transformations (like some CFG simplification or whatever), the Branch's child ends up just being a CompareEq or the like. Point is, if we know that the child of the Branch is one of the Compare's, then we don't need to look at the use kind. If the use kind is either BooleanUse or UntypedUse, then the code does exactly what it should do. If the use kind was anything else, then this will always OSR exit, in which case we can propagate whatever we like to the successors (and so in that case, this code is correct as well).
(In reply to comment #14) > (In reply to comment #13) > > Comment on attachment 254684 [details] > > the patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=254684&action=review > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:155 > > > + if (m_offset == std::numeric_limits<int>::min()) > > > + return Relationship(); > > > > It would be good to have a test covering this case. > > Good idea! I can't easily come up with what this test would look like. I might try to come back to this later. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:309 > > > + // Make sure that if we have a LessThan, then it's first. > > > + if (b.m_kind == LessThan) > > > + std::swap(a, b); > > > + > > > + // Make sure that if we have a NotEqual, then it's first. > > > + if (b.m_kind == NotEqual) > > > + std::swap(a, b); > > > > I would move those to mergeImpl() and remove the comments. > > I don't think so - we cannot swap *this and other in mergeImpl(). :-) > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:332 > > > + Relationship filter(const Relationship& other) const > > > > TODO: review this. > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:341 > > > + // this to assume that we different offsets anytime that everything but the offset is > > > > "assume that we different offsets anytime" > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:436 > > > + int minRightValue; > > > + if (m_right->isInt32Constant()) > > > + minRightValue = m_right->asInt32(); > > > + else > > > + minRightValue = std::numeric_limits<int>::min(); > > > > Maybe simpler like this? > > > > int minRightValue = std::numeric_limits<int>::min(); > > if (m_right->isInt32Constant()) > > minRightValue = m_right->asInt32(); > > That works, too. Fixed. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:440 > > > + return clampedSum(minRightValue, m_offset); > > > > I am not following this case. > > > > If we are here, we have (kind == Equal or kind == NotEqual). > > Why is the mind value of NotEqual @b + Constant? > > Ooops. That's a bug. > > I added NotEqual after writing this code. The case for LessThan, above, > which returns std::numeric_limits<int>::min() should also do the same for > NotEqual. Fixed. And I added a test. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:455 > > > + int maxRightValue; > > > + if (m_right->isInt32Constant()) > > > + maxRightValue = m_right->asInt32(); > > > + else > > > + maxRightValue = std::numeric_limits<int>::max(); > > > > "Simpler" version here too. > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:459 > > > + return clampedSum(maxRightValue, m_offset); > > > > Same question about NotEqual > > Ditto, bug. Ditto, fixed. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:495 > > > + ASSERT(sameNodesAs(other)); > > > > An other precondition is that neither node has the relation "GreaterThan". > > True! I should add that assert. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:520 > > > + // this to assume that we different offsets anytime that everything but the offset is > > > > "that we different offsets" > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:531 > > > + // Saying that you might be B when you've already said that you're anything > > > + // but A, where A and B are different, is a tautology. You could just say > > > + // that you're anything but A. > > > > Maybe just write an example as this is a pretty obvious case? > > // Adding "(a == b + 1)" to "(a != b + 5)" has no value. > > OK. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:548 > > > + // If we have C > D, then we could keep both claims, but we are cheap, so we > > > + // don't. We just use the NotEqual. > > > > Wouldn't it be easier to implement it instead of justifying not having it? :) > > By "cheap" I mean that we are trying to accelerate convergence. Any time > that we create more relationships, we create more things to merge, and > possibly increase the number of fixpoint iterations. > > Not implementing something we don't think is valuable is kind of a > convergence hack - fewer relationships means less time spent processing > relationships. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:611 > > > + std::max(m_offset, other.m_offset) + 1); > > > > Not a fan of the implicit overflow here but it's harmless. > > > > It would be good to have tests for those cases though. > > Interesting. I didn't want this overflow. I'll guard this with > sumOverflows() or something. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:645 > > > + // Before we do anything, make sure that we have a zero constant at the top. > > > > I would also say why in addition to what. > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:939 > > > + if (!node->child2()->isInt32Constant()) > > > > No love for (constant + @value)? > > See DFGStrenghtReductionPhase.cpp. It canonicalizes constant+@value to > @value+constant. > > This is also why we don't handle @value-constant. It would have been > canonicalized to @value+(-constant). > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:987 > > > + if (!sumOverflows<int>(std::numeric_limits<int>::max(), -offset, 1)) { > > > > I don't follow this. > > > > Say way have: > > @1 = @x + 1000; > > @2 = @1 + 10; > > > > You add the relationship @1 < 0 + max - 10 + 1. > > > > Say that we > > I'm curious what you were thinking. :-) > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1274 > > > + > > > > 1274 lines! The original CSS JIT was small than that :) Still need to address these other comments.
Created attachment 254964 [details] the patch Patch which addresses some of the feedback.
Attachment 254964 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:313: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:864: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:864: Multi line control clauses should use braces. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1139: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1188: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 5 in 22 files If any of these errors are false positives, please file a bug against check-webkit-style.
(In reply to comment #20) > (In reply to comment #14) > > (In reply to comment #13) > > > Comment on attachment 254684 [details] > > > the patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=254684&action=review > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:155 > > > > + if (m_offset == std::numeric_limits<int>::min()) > > > > + return Relationship(); > > > > > > It would be good to have a test covering this case. > > > > Good idea! > > I can't easily come up with what this test would look like. I might try to > come back to this later. > > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:309 > > > > + // Make sure that if we have a LessThan, then it's first. > > > > + if (b.m_kind == LessThan) > > > > + std::swap(a, b); > > > > + > > > > + // Make sure that if we have a NotEqual, then it's first. > > > > + if (b.m_kind == NotEqual) > > > > + std::swap(a, b); > > > > > > I would move those to mergeImpl() and remove the comments. > > > > I don't think so - we cannot swap *this and other in mergeImpl(). :-) > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:332 > > > > + Relationship filter(const Relationship& other) const > > > > > > TODO: review this. > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:341 > > > > + // this to assume that we different offsets anytime that everything but the offset is > > > > > > "assume that we different offsets anytime" > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:436 > > > > + int minRightValue; > > > > + if (m_right->isInt32Constant()) > > > > + minRightValue = m_right->asInt32(); > > > > + else > > > > + minRightValue = std::numeric_limits<int>::min(); > > > > > > Maybe simpler like this? > > > > > > int minRightValue = std::numeric_limits<int>::min(); > > > if (m_right->isInt32Constant()) > > > minRightValue = m_right->asInt32(); > > > > That works, too. > > Fixed. > > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:440 > > > > + return clampedSum(minRightValue, m_offset); > > > > > > I am not following this case. > > > > > > If we are here, we have (kind == Equal or kind == NotEqual). > > > Why is the mind value of NotEqual @b + Constant? > > > > Ooops. That's a bug. > > > > I added NotEqual after writing this code. The case for LessThan, above, > > which returns std::numeric_limits<int>::min() should also do the same for > > NotEqual. > > Fixed. And I added a test. > > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:455 > > > > + int maxRightValue; > > > > + if (m_right->isInt32Constant()) > > > > + maxRightValue = m_right->asInt32(); > > > > + else > > > > + maxRightValue = std::numeric_limits<int>::max(); > > > > > > "Simpler" version here too. > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:459 > > > > + return clampedSum(maxRightValue, m_offset); > > > > > > Same question about NotEqual > > > > Ditto, bug. > > Ditto, fixed. > > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:495 > > > > + ASSERT(sameNodesAs(other)); > > > > > > An other precondition is that neither node has the relation "GreaterThan". > > > > True! I should add that assert. > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:520 > > > > + // this to assume that we different offsets anytime that everything but the offset is > > > > > > "that we different offsets" > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:531 > > > > + // Saying that you might be B when you've already said that you're anything > > > > + // but A, where A and B are different, is a tautology. You could just say > > > > + // that you're anything but A. > > > > > > Maybe just write an example as this is a pretty obvious case? > > > // Adding "(a == b + 1)" to "(a != b + 5)" has no value. > > > > OK. > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:548 > > > > + // If we have C > D, then we could keep both claims, but we are cheap, so we > > > > + // don't. We just use the NotEqual. > > > > > > Wouldn't it be easier to implement it instead of justifying not having it? :) > > > > By "cheap" I mean that we are trying to accelerate convergence. Any time > > that we create more relationships, we create more things to merge, and > > possibly increase the number of fixpoint iterations. > > > > Not implementing something we don't think is valuable is kind of a > > convergence hack - fewer relationships means less time spent processing > > relationships. > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:611 > > > > + std::max(m_offset, other.m_offset) + 1); > > > > > > Not a fan of the implicit overflow here but it's harmless. > > > > > > It would be good to have tests for those cases though. > > > > Interesting. I didn't want this overflow. I'll guard this with > > sumOverflows() or something. Fixed. > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:645 > > > > + // Before we do anything, make sure that we have a zero constant at the top. > > > > > > I would also say why in addition to what. > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:939 > > > > + if (!node->child2()->isInt32Constant()) > > > > > > No love for (constant + @value)? > > > > See DFGStrenghtReductionPhase.cpp. It canonicalizes constant+@value to > > @value+constant. > > > > This is also why we don't handle @value-constant. It would have been > > canonicalized to @value+(-constant). > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:987 > > > > + if (!sumOverflows<int>(std::numeric_limits<int>::max(), -offset, 1)) { > > > > > > I don't follow this. > > > > > > Say way have: > > > @1 = @x + 1000; > > > @2 = @1 + 10; > > > > > > You add the relationship @1 < 0 + max - 10 + 1. > > > > > > Say that we > > > > I'm curious what you were thinking. :-) > > > > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1274 > > > > + > > > > > > 1274 lines! The original CSS JIT was small than that :) > > Still need to address these other comments.
(In reply to comment #19) > (In reply to comment #17) > > Comment on attachment 254684 [details] > > the patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=254684&action=review > > > > Some more comments. > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:331 > > > + // In some cases, it will do something conservative. It's always safe for this to return > > > + // *this, or to return other. It'll do that sometimes, mainly to accelerate convergence for > > > + // things that we don't think are important enough to slow down the analysis. > > > > This is pretty clear, I think the null case makes things more complicated. > > > > It would be good to justify every use of the null return. Otherwise anyone > > will be afraid to touch this code in the future because they won't know why > > some cases return null instead of *this. > > Null return means: please represent the intersection of the two > relationships by explicitly keeping both relationships. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:352 > > > + // Useful helper for flipping. > > > > This comment does not help enough IMHO. It would be more helpful to say that > > you only implement check for LessThan and flip the relation when handling > > GreaterThan. > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:384 > > > + // @a != @b + C > > > + // @a < @b + D > > > > Reading this patch for a while now, I really like those little examples. > > They help a lot. > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:417 > > > + return Relationship(); > > > > I don't know if you have a rationale for this. I am thinking that keeping > > the LessThan would be valuable. In general I see code dealing mostly with > > positive numbers. Knowing an upper bound seems more useful on average. > > That's what this is doing. Returning null means that we keep both > relationships. This is how we get things like 0 <= @x < array.length. If > we returned *this or if we returned *other, we'd only get 0 <= @x or @x < > array.length but not both. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:743 > > > + Relationship relationship; > > > > relationship -> relationshipForTrueCase or something like that? > > Good idea! Fixed. I used "relationshipForTrue" since it's shorter and just as meaningful. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:755 > > > + } else { > > > > This could be if (terminal->child1().useKind() == BooleanUse) > > It could be, but it doesn't have to be. We could have a FixupPhase decide > that a Branch has an UntypedUse edge, but by later transformations (like > some CFG simplification or whatever), the Branch's child ends up just being > a CompareEq or the like. > > Point is, if we know that the child of the Branch is one of the Compare's, > then we don't need to look at the use kind. If the use kind is either > BooleanUse or UntypedUse, then the code does exactly what it should do. If > the use kind was anything else, then this will always OSR exit, in which > case we can propagate whatever we like to the successors (and so in that > case, this code is correct as well).
Comment on attachment 254964 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=254964&action=review > Source/JavaScriptCore/ChangeLog:35 > + * tests/stress/add-overflows-after-not-equal.js: Added. > + * tests/stress/sub-overflows-after-not-equal.js: Added. IMHO, it would be worth adding stress tests to check anything you can come up with. It's not exactly a simple patch and we'll have very little time to discover any unforeseen side effect. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:714 > + bool changed = true; > + while (changed) { I think it would be good to explain the convergency trick on < and > with 1, 0, -1 that you explained in your office. Otherwise it seems a bit mysterious that this does not run forever. > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1137 > + if (m_seenBlocks.add(target)) { What is inside the if() is pretty self contained. If it is possible to move it to a function, that may make the code more readable. Maybe: filterLiveRelationships(relationshipMap, target, [] (Node* node, const Vector<Relationship>& liveRelationships) ? > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1170 > + // are using RPO. RPO -> reverse post-order traversal. I am not good at remembering acronyms :) > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1181 > + Vector<Relationship> values; values->mergedRelationships or something like that?
(In reply to comment #25) > Comment on attachment 254964 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=254964&action=review > > > Source/JavaScriptCore/ChangeLog:35 > > + * tests/stress/add-overflows-after-not-equal.js: Added. > > + * tests/stress/sub-overflows-after-not-equal.js: Added. > > IMHO, it would be worth adding stress tests to check anything you can come > up with. > > It's not exactly a simple patch and we'll have very little time to discover > any unforeseen side effect. Agreed. I'll try to come up with more tests. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:714 > > + bool changed = true; > > + while (changed) { > > I think it would be good to explain the convergency trick on < and > with 1, > 0, -1 that you explained in your office. Otherwise it seems a bit mysterious > that this does not run forever. OK. I will try to say something about this. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1137 > > + if (m_seenBlocks.add(target)) { > > What is inside the if() is pretty self contained. If it is possible to move > it to a function, that may make the code more readable. > > Maybe: > filterLiveRelationships(relationshipMap, target, [] (Node* node, const > Vector<Relationship>& liveRelationships) > ? I'll try that. > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1170 > > + // are using RPO. > > RPO -> reverse post-order traversal. I am not good at remembering acronyms :) OK! > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1181 > > + Vector<Relationship> values; > > values->mergedRelationships or something like that? OK.
Latest perf data. Benchmark report for SunSpider, LongSpider, V8Spider, Octane, Kraken, JSRegress, AsmBench, and CompressionBench on dethklok (MacBookPro9,1). VMs tested: "TipOfTree" at /Volumes/Data/pizlo/secondary/OpenSource/WebKitBuild/Release/jsc (r185618) "ABC" at /Volumes/Data/pizlo/tertiary/OpenSource/WebKitBuild/Release/jsc (r185618) Collected 6 samples per benchmark/VM, with 6 VM invocations per benchmark. Emitted a call to gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds. TipOfTree ABC SunSpider: 3d-cube 5.1960+-0.1585 ? 5.2406+-0.2075 ? 3d-morph 5.9571+-0.2759 5.9016+-0.1508 3d-raytrace 6.6202+-0.2594 ? 6.7535+-0.2991 ? might be 1.0201x slower access-binary-trees 2.4146+-0.1719 ? 2.5492+-0.2759 ? might be 1.0558x slower access-fannkuch 6.5947+-0.9682 6.3028+-0.3708 might be 1.0463x faster access-nbody 3.2017+-0.2743 2.9415+-0.0694 might be 1.0884x faster access-nsieve 3.1820+-0.1015 ? 3.3265+-0.1480 ? might be 1.0454x slower bitops-3bit-bits-in-byte 1.7332+-0.1737 1.6407+-0.0325 might be 1.0563x faster bitops-bits-in-byte 4.0867+-0.3842 3.9713+-0.3355 might be 1.0291x faster bitops-bitwise-and 2.2540+-0.0988 ? 2.2602+-0.1528 ? bitops-nsieve-bits 3.3277+-0.1836 3.2922+-0.0401 might be 1.0108x faster controlflow-recursive 3.0985+-0.1947 3.0236+-0.2647 might be 1.0248x faster crypto-aes 4.7303+-0.1611 ? 4.8579+-0.5297 ? might be 1.0270x slower crypto-md5 2.7583+-0.0762 2.7141+-0.0592 might be 1.0163x faster crypto-sha1 3.9282+-0.5834 3.7892+-0.3000 might be 1.0367x faster date-format-tofte 9.5456+-0.2658 9.3586+-0.2512 might be 1.0200x faster date-format-xparb 5.7915+-0.1684 ? 6.0771+-0.5477 ? might be 1.0493x slower math-cordic 3.2695+-0.4314 3.2180+-0.3593 might be 1.0160x faster math-partial-sums 5.7795+-0.7379 5.6410+-0.6846 might be 1.0246x faster math-spectral-norm 2.0442+-0.0407 2.0131+-0.0191 might be 1.0154x faster regexp-dna 7.7138+-0.6036 7.5404+-0.2039 might be 1.0230x faster string-base64 5.1719+-0.2584 5.0114+-0.1968 might be 1.0320x faster string-fasta 6.9038+-0.1431 ? 7.1592+-0.5351 ? might be 1.0370x slower string-tagcloud 9.4673+-0.2651 ? 9.8449+-0.5560 ? might be 1.0399x slower string-unpack-code 21.0815+-0.9895 ? 21.9985+-1.2319 ? might be 1.0435x slower string-validate-input 6.1742+-0.1756 6.0006+-0.1562 might be 1.0289x faster <arithmetic> 5.4625+-0.0463 ? 5.4780+-0.0994 ? might be 1.0028x slower TipOfTree ABC LongSpider: 3d-cube 890.6830+-38.7655 ! 1140.6213+-39.8872 ! definitely 1.2806x slower 3d-morph 1529.4299+-5.5338 1528.6065+-4.7346 3d-raytrace 700.0050+-5.5140 ? 705.2288+-22.6030 ? access-binary-trees 1012.2520+-9.0308 ? 1015.2680+-8.4333 ? access-fannkuch 342.5678+-9.8797 341.9983+-7.5917 access-nbody 622.6018+-58.3607 588.4920+-0.8545 might be 1.0580x faster access-nsieve 478.9797+-7.0967 474.3830+-6.4629 bitops-3bit-bits-in-byte 44.4413+-0.7706 ? 44.4815+-0.8591 ? bitops-bits-in-byte 99.3187+-0.8950 98.9467+-1.4040 bitops-nsieve-bits 427.7233+-19.9629 419.5245+-2.4038 might be 1.0195x faster controlflow-recursive 494.6224+-11.3762 ^ 471.3984+-9.7109 ^ definitely 1.0493x faster crypto-aes 723.7477+-37.0114 685.7591+-23.5605 might be 1.0554x faster crypto-md5 524.3218+-6.3999 ? 530.9508+-20.2085 ? might be 1.0126x slower crypto-sha1 713.1667+-29.8680 ^ 660.7652+-14.5036 ^ definitely 1.0793x faster date-format-tofte 756.8373+-9.7671 ^ 710.7300+-5.3521 ^ definitely 1.0649x faster date-format-xparb 781.8886+-39.3341 ? 815.0981+-22.3160 ? might be 1.0425x slower hash-map 184.3162+-4.6735 182.2640+-2.4651 might be 1.0113x faster math-cordic 577.1937+-3.6865 ? 582.1088+-16.0278 ? math-partial-sums 514.1036+-13.0745 510.2251+-5.0995 math-spectral-norm 566.6598+-5.3762 ? 571.9282+-5.3573 ? string-base64 415.4056+-14.1096 411.6092+-3.7756 string-fasta 437.4764+-4.0240 ? 438.6787+-3.1826 ? string-tagcloud 194.3930+-2.1499 ? 199.0745+-5.0888 ? might be 1.0241x slower <geometric> 458.2025+-3.3464 ? 458.2367+-1.7082 ? might be 1.0001x slower TipOfTree ABC V8Spider: crypto 58.4829+-1.3024 57.0349+-2.3922 might be 1.0254x faster deltablue 104.2959+-3.7325 ? 113.0036+-32.3463 ? might be 1.0835x slower earley-boyer 48.5331+-1.9081 ? 49.9815+-2.8647 ? might be 1.0298x slower raytrace 41.8403+-0.9828 ? 43.2250+-3.3068 ? might be 1.0331x slower regexp 84.2419+-23.0458 74.9963+-1.1924 might be 1.1233x faster richards 81.7282+-2.6755 81.1254+-3.3964 splay 39.6808+-1.6475 ? 40.8530+-2.0333 ? might be 1.0295x slower <geometric> 61.4565+-2.2759 ? 61.6048+-2.1715 ? might be 1.0024x slower TipOfTree ABC Octane: encrypt 0.20318+-0.00076 0.20124+-0.00870 decrypt 3.76633+-0.39142 ^ 3.28584+-0.01509 ^ definitely 1.1462x faster deltablue x2 0.19597+-0.00155 ^ 0.18933+-0.00223 ^ definitely 1.0351x faster earley 0.39422+-0.00179 0.39336+-0.00445 boyer 5.23743+-0.23507 ? 5.25768+-0.17408 ? navier-stokes x2 5.23417+-0.15376 5.12778+-0.01154 might be 1.0207x faster raytrace x2 1.31490+-0.05422 1.29543+-0.04545 might be 1.0150x faster richards x2 0.12803+-0.00158 ? 0.13015+-0.00317 ? might be 1.0165x slower splay x2 0.39624+-0.00310 ? 0.39799+-0.00518 ? regexp x2 29.78264+-0.31076 29.40092+-0.17937 might be 1.0130x faster pdfjs x2 42.51933+-0.31240 ? 42.90453+-0.44607 ? mandreel x2 51.21850+-0.50385 ? 54.23294+-9.25712 ? might be 1.0589x slower gbemu x2 44.73400+-2.52451 ? 46.22316+-5.01127 ? might be 1.0333x slower closure 0.56506+-0.00232 0.56390+-0.00189 jquery 7.36495+-0.03864 7.34849+-0.05585 box2d x2 11.89721+-0.03822 ? 12.01815+-0.31557 ? might be 1.0102x slower zlib x2 398.51021+-2.74132 396.72526+-3.30054 typescript x2 825.53719+-16.44883 820.23372+-15.29671 <geometric> 6.60432+-0.04585 6.58325+-0.10602 might be 1.0032x faster TipOfTree ABC Kraken: ai-astar 240.346+-7.598 233.631+-5.403 might be 1.0287x faster audio-beat-detection 85.089+-7.178 83.334+-1.936 might be 1.0211x faster audio-dft 120.484+-2.807 ? 127.918+-13.981 ? might be 1.0617x slower audio-fft 70.741+-2.293 ? 71.485+-1.953 ? might be 1.0105x slower audio-oscillator 77.358+-1.535 ? 78.441+-2.207 ? might be 1.0140x slower imaging-darkroom 106.393+-3.655 105.664+-2.095 imaging-desaturate 64.450+-2.115 62.253+-2.412 might be 1.0353x faster imaging-gaussian-blur 117.106+-5.205 ^ 108.681+-1.639 ^ definitely 1.0775x faster json-parse-financial 47.716+-1.949 ? 47.970+-1.737 ? json-stringify-tinderbox 33.215+-9.437 31.445+-2.748 might be 1.0563x faster stanford-crypto-aes 59.770+-1.400 58.646+-0.550 might be 1.0192x faster stanford-crypto-ccm 48.867+-0.594 ? 49.508+-1.428 ? might be 1.0131x slower stanford-crypto-pbkdf2 113.197+-2.883 ^ 109.559+-0.480 ^ definitely 1.0332x faster stanford-crypto-sha256-iterative 45.042+-2.097 43.202+-1.455 might be 1.0426x faster <arithmetic> 87.841+-0.595 86.553+-1.054 might be 1.0149x faster TipOfTree ABC JSRegress: abc-forward-loop-equal 73.6025+-0.9687 ^ 47.9151+-1.3648 ^ definitely 1.5361x faster abc-postfix-backward-loop 73.9181+-2.1473 ^ 48.4234+-2.0258 ^ definitely 1.5265x faster abc-simple-backward-loop 73.5877+-2.1058 ^ 46.6553+-0.4208 ^ definitely 1.5773x faster abc-simple-forward-loop 73.1920+-0.9242 ^ 48.1729+-1.6541 ^ definitely 1.5194x faster abs-boolean 2.7342+-0.0805 ? 2.7607+-0.1672 ? adapt-to-double-divide 16.6711+-0.2743 ? 16.9772+-0.4318 ? might be 1.0184x slower aliased-arguments-getbyval 1.3217+-0.0406 ? 1.3372+-0.0852 ? might be 1.0117x slower allocate-big-object 2.8967+-0.0636 ? 3.0623+-0.2078 ? might be 1.0572x slower arguments-named-and-reflective 12.4870+-0.3296 ? 12.6454+-0.6824 ? might be 1.0127x slower arguments-out-of-bounds 14.6392+-0.1548 ? 15.6589+-1.6785 ? might be 1.0697x slower arguments-strict-mode 12.2167+-3.1572 11.3076+-1.2321 might be 1.0804x faster arguments 10.5094+-2.2274 9.9008+-0.8508 might be 1.0615x faster arity-mismatch-inlining 0.9648+-0.1631 0.8715+-0.0195 might be 1.1071x faster array-access-polymorphic-structure 7.3603+-0.9702 6.9139+-0.1238 might be 1.0646x faster array-nonarray-polymorhpic-access 33.0238+-1.3201 32.1090+-0.9613 might be 1.0285x faster array-prototype-every 88.2775+-3.0355 87.9590+-2.3232 array-prototype-forEach 85.1885+-2.5273 ? 86.4713+-2.3871 ? might be 1.0151x slower array-prototype-map 93.3508+-1.7576 92.7841+-4.1128 array-prototype-reduce 87.7057+-5.3469 83.1573+-1.9805 might be 1.0547x faster array-prototype-reduceRight 86.9582+-2.7088 82.9364+-1.6607 might be 1.0485x faster array-prototype-some 87.3272+-2.8074 86.4393+-3.6196 might be 1.0103x faster array-splice-contiguous 43.0173+-1.8810 ? 43.0222+-1.8602 ? array-with-double-add 4.2592+-0.0470 4.2292+-0.0847 array-with-double-increment 3.4484+-0.3510 3.3625+-0.1289 might be 1.0255x faster array-with-double-mul-add 5.3029+-0.1488 5.2023+-0.0937 might be 1.0193x faster array-with-double-sum 3.3862+-0.0677 ? 3.4049+-0.2426 ? array-with-int32-add-sub 6.8784+-0.1067 6.8080+-0.0358 might be 1.0103x faster array-with-int32-or-double-sum 3.3977+-0.0422 ? 3.5017+-0.2115 ? might be 1.0306x slower ArrayBuffer-DataView-alloc-large-long-lived 39.8325+-2.3809 37.1976+-1.5283 might be 1.0708x faster ArrayBuffer-DataView-alloc-long-lived 14.6883+-0.5103 ? 15.5661+-1.5088 ? might be 1.0598x slower ArrayBuffer-Int32Array-byteOffset 3.9935+-0.3258 3.8632+-0.1678 might be 1.0337x faster ArrayBuffer-Int8Array-alloc-large-long-lived 39.0132+-3.3441 38.9919+-0.9911 ArrayBuffer-Int8Array-alloc-long-lived-buffer 23.8928+-3.4078 22.8375+-1.4626 might be 1.0462x faster ArrayBuffer-Int8Array-alloc-long-lived 14.8730+-1.7634 14.5287+-1.8609 might be 1.0237x faster ArrayBuffer-Int8Array-alloc 12.5103+-2.5156 10.4500+-0.2727 might be 1.1971x faster asmjs_bool_bug 7.9433+-0.2817 7.8689+-0.2275 assign-custom-setter-polymorphic 3.3749+-0.4290 3.3092+-0.3704 might be 1.0198x faster assign-custom-setter 4.6082+-0.3362 4.3802+-0.0676 might be 1.0520x faster basic-set 9.6806+-0.5041 9.5392+-0.1386 might be 1.0148x faster big-int-mul 4.1491+-0.1607 4.0790+-0.0424 might be 1.0172x faster boolean-test 3.2988+-0.3005 3.2381+-0.1153 might be 1.0187x faster branch-fold 4.3620+-0.4053 ? 4.5640+-0.6007 ? might be 1.0463x slower branch-on-string-as-boolean 21.5431+-2.4735 20.7898+-1.5859 might be 1.0362x faster by-val-generic 9.0096+-0.5990 8.5437+-0.2453 might be 1.0545x faster call-spread-apply 30.7021+-2.1442 29.5722+-0.6297 might be 1.0382x faster call-spread-call 25.4045+-0.5153 ? 26.6822+-1.3813 ? might be 1.0503x slower captured-assignments 0.5625+-0.0419 0.5573+-0.0709 cast-int-to-double 5.5354+-0.2060 5.3190+-0.1547 might be 1.0407x faster cell-argument 9.3733+-0.9406 8.7155+-0.3000 might be 1.0755x faster cfg-simplify 3.3274+-0.8132 2.9451+-0.1031 might be 1.1298x faster chain-getter-access 9.8833+-1.2247 9.6292+-0.4128 might be 1.0264x faster cmpeq-obj-to-obj-other 12.6815+-1.0205 ? 12.7437+-0.8447 ? constant-test 5.0924+-0.1910 ? 5.1292+-0.1775 ? create-lots-of-functions 11.7617+-0.3572 ? 11.8509+-0.3374 ? cse-new-array-buffer 2.5133+-0.0367 ? 2.6012+-0.1673 ? might be 1.0350x slower cse-new-array 2.6385+-0.0383 ? 2.7156+-0.1008 ? might be 1.0292x slower DataView-custom-properties 42.7686+-2.8926 ? 43.5024+-2.6081 ? might be 1.0172x slower deconstructing-parameters-overridden-by-function 0.6158+-0.0697 0.5905+-0.0368 might be 1.0428x faster delay-tear-off-arguments-strictmode 14.7164+-0.6468 14.0817+-0.2377 might be 1.0451x faster deltablue-varargs 210.6804+-1.0489 ? 214.3517+-3.9082 ? might be 1.0174x slower destructuring-arguments 17.5636+-0.4453 17.4349+-0.5357 destructuring-swap 5.1857+-0.1475 5.1167+-0.0710 might be 1.0135x faster direct-arguments-getbyval 1.3606+-0.0956 ? 1.4508+-0.1937 ? might be 1.0662x slower div-boolean-double 5.4179+-0.3406 5.3109+-0.1377 might be 1.0202x faster div-boolean 7.8466+-0.0374 7.8442+-0.0523 double-get-by-val-out-of-bounds 4.7781+-0.1063 4.6592+-0.1185 might be 1.0255x faster double-pollution-getbyval 9.0463+-0.2135 8.9827+-0.1291 double-pollution-putbyoffset 4.5760+-0.5044 4.3854+-0.0692 might be 1.0435x faster double-real-use 29.9740+-0.8371 ? 30.1638+-0.8119 ? double-to-int32-typed-array-no-inline 2.5520+-0.1843 2.5119+-0.2927 might be 1.0160x faster double-to-int32-typed-array 2.1267+-0.1972 ? 2.1704+-0.1837 ? might be 1.0205x slower double-to-uint32-typed-array-no-inline 2.8360+-0.3013 2.7209+-0.3332 might be 1.0423x faster double-to-uint32-typed-array 2.0821+-0.1314 ? 2.2505+-0.3216 ? might be 1.0809x slower elidable-new-object-dag 43.6725+-0.9335 ? 45.4315+-2.7797 ? might be 1.0403x slower elidable-new-object-roflcopter 44.4695+-1.4983 44.4169+-1.0016 elidable-new-object-then-call 41.1300+-2.4055 39.5589+-0.6322 might be 1.0397x faster elidable-new-object-tree 45.4648+-1.3264 45.4292+-1.0665 empty-string-plus-int 5.7161+-0.1171 5.5635+-0.1710 might be 1.0274x faster emscripten-cube2hash 38.7563+-1.6686 ? 38.9558+-1.2127 ? exit-length-on-plain-object 14.8441+-1.6145 ? 16.0308+-2.7271 ? might be 1.0799x slower external-arguments-getbyval 1.3586+-0.1526 1.2852+-0.0952 might be 1.0571x faster external-arguments-putbyval 2.6578+-0.2187 2.5067+-0.2570 might be 1.0603x faster fixed-typed-array-storage-var-index 1.2992+-0.1467 1.2492+-0.0631 might be 1.0400x faster fixed-typed-array-storage 0.9058+-0.0413 ? 0.9875+-0.1856 ? might be 1.0902x slower Float32Array-matrix-mult 4.9937+-0.3738 4.9020+-0.5973 might be 1.0187x faster Float32Array-to-Float64Array-set 57.9413+-3.1456 ^ 52.4293+-1.9126 ^ definitely 1.1051x faster Float64Array-alloc-long-lived 87.2984+-2.0573 ? 87.9021+-2.2689 ? Float64Array-to-Int16Array-set 72.3487+-1.1167 70.5978+-1.4554 might be 1.0248x faster fold-double-to-int 13.7404+-0.3264 ? 13.8574+-0.5717 ? fold-get-by-id-to-multi-get-by-offset-rare-int 10.8985+-0.5474 ? 11.2330+-1.7562 ? might be 1.0307x slower fold-get-by-id-to-multi-get-by-offset 9.9895+-1.5700 ? 10.4126+-0.6623 ? might be 1.0424x slower fold-multi-get-by-offset-to-get-by-offset 9.3152+-0.9816 ? 9.3357+-0.7551 ? fold-multi-get-by-offset-to-poly-get-by-offset 9.2593+-0.8379 ? 9.4773+-0.6496 ? might be 1.0235x slower fold-multi-put-by-offset-to-poly-put-by-offset 10.1844+-1.2198 ? 10.4349+-0.7655 ? might be 1.0246x slower fold-multi-put-by-offset-to-put-by-offset 8.3315+-0.7275 8.0023+-0.4197 might be 1.0411x faster fold-multi-put-by-offset-to-replace-or-transition-put-by-offset 9.8145+-0.4245 ? 10.8479+-0.9448 ? might be 1.1053x slower fold-put-by-id-to-multi-put-by-offset 9.6420+-0.8663 ? 10.3847+-0.8002 ? might be 1.0770x slower fold-put-structure 7.5278+-1.3544 7.1348+-1.2024 might be 1.0551x faster for-of-iterate-array-entries 4.7769+-0.3310 ? 4.7933+-0.2735 ? for-of-iterate-array-keys 3.9648+-0.2261 3.8217+-0.0824 might be 1.0375x faster for-of-iterate-array-values 3.6891+-0.0659 ? 3.8044+-0.0678 ? might be 1.0313x slower fround 21.7183+-1.5143 21.1999+-0.6045 might be 1.0245x faster ftl-library-inlining-dataview 67.8471+-5.4248 66.2961+-3.1446 might be 1.0234x faster ftl-library-inlining 76.8132+-15.6186 76.2906+-18.2989 function-dot-apply 2.3559+-0.2435 ? 2.4719+-0.3391 ? might be 1.0492x slower function-test 3.0770+-0.1929 3.0055+-0.0296 might be 1.0238x faster function-with-eval 104.0791+-4.7794 ? 105.6725+-4.5839 ? might be 1.0153x slower gcse-poly-get-less-obvious 18.7931+-0.8232 18.5475+-0.8243 might be 1.0132x faster gcse-poly-get 20.6963+-1.9458 19.8279+-0.9306 might be 1.0438x faster gcse 4.4638+-0.2140 4.4188+-0.2069 might be 1.0102x faster get-by-id-bimorphic-check-structure-elimination-simple 2.8201+-0.1125 ? 2.9106+-0.1834 ? might be 1.0321x slower get-by-id-bimorphic-check-structure-elimination 6.2723+-0.5162 6.0590+-0.1227 might be 1.0352x faster get-by-id-chain-from-try-block 7.4889+-1.6102 6.9049+-0.2186 might be 1.0846x faster get-by-id-check-structure-elimination 5.1661+-0.1016 ? 5.4313+-0.5828 ? might be 1.0513x slower get-by-id-proto-or-self 19.1172+-1.4398 18.6596+-1.7199 might be 1.0245x faster get-by-id-quadmorphic-check-structure-elimination-simple 3.0314+-0.0872 ? 3.0980+-0.2665 ? might be 1.0220x slower get-by-id-self-or-proto 19.2998+-1.8863 18.7932+-0.8972 might be 1.0270x faster get-by-val-out-of-bounds 4.5103+-0.1200 4.4760+-0.0484 get_callee_monomorphic 3.2875+-0.7785 3.0190+-0.3264 might be 1.0889x faster get_callee_polymorphic 3.7642+-0.0717 ? 4.1169+-0.5540 ? might be 1.0937x slower getter-no-activation 5.0647+-0.2828 5.0073+-0.1746 might be 1.0115x faster getter-prototype 15.0355+-0.3293 ? 15.1189+-0.2121 ? getter-richards 123.0798+-4.1630 ? 123.6789+-3.4508 ? getter 6.0339+-0.7983 ? 6.3255+-0.7907 ? might be 1.0483x slower global-var-const-infer-fire-from-opt 0.9434+-0.0488 ? 0.9860+-0.1335 ? might be 1.0452x slower global-var-const-infer 0.9741+-0.1541 0.8835+-0.1054 might be 1.1025x faster HashMap-put-get-iterate-keys 30.2976+-2.4252 ? 30.5833+-1.8594 ? HashMap-put-get-iterate 32.3424+-0.9235 32.2024+-1.1524 HashMap-string-put-get-iterate 31.9597+-1.4072 ? 33.0144+-0.6667 ? might be 1.0330x slower hoist-make-rope 12.8953+-1.4380 12.6736+-0.8385 might be 1.0175x faster hoist-poly-check-structure-effectful-loop 5.3238+-0.2068 5.2369+-0.2091 might be 1.0166x faster hoist-poly-check-structure 3.8741+-0.2311 3.7651+-0.1186 might be 1.0290x faster imul-double-only 8.6515+-1.2234 ? 8.9180+-0.1768 ? might be 1.0308x slower imul-int-only 9.8797+-0.1847 ? 10.1685+-0.6209 ? might be 1.0292x slower imul-mixed 8.3288+-0.1564 ? 8.8255+-0.9465 ? might be 1.0596x slower in-four-cases 23.0736+-0.4894 ? 23.4517+-0.8238 ? might be 1.0164x slower in-one-case-false 11.0955+-0.0862 ? 11.2256+-0.2210 ? might be 1.0117x slower in-one-case-true 11.0851+-0.1177 ? 11.4117+-0.2756 ? might be 1.0295x slower in-two-cases 11.4632+-0.3421 ? 11.6889+-0.4664 ? might be 1.0197x slower indexed-properties-in-objects 3.3645+-0.6451 3.0977+-0.3648 might be 1.0862x faster infer-closure-const-then-mov-no-inline 4.1952+-0.3983 ? 4.3245+-0.6095 ? might be 1.0308x slower infer-closure-const-then-mov 20.1927+-0.6457 19.8562+-0.4493 might be 1.0169x faster infer-closure-const-then-put-to-scope-no-inline 13.1636+-0.9691 12.7080+-0.1427 might be 1.0358x faster infer-closure-const-then-put-to-scope 21.7340+-0.8355 ? 23.4668+-2.0150 ? might be 1.0797x slower infer-closure-const-then-reenter-no-inline 54.5461+-1.4107 ? 55.6296+-2.4980 ? might be 1.0199x slower infer-closure-const-then-reenter 22.7887+-1.4661 ? 23.3534+-1.4303 ? might be 1.0248x slower infer-constant-global-property 3.6449+-0.1310 ? 3.7842+-0.2367 ? might be 1.0382x slower infer-constant-property 2.8054+-0.1015 ? 2.8993+-0.3746 ? might be 1.0334x slower infer-one-time-closure-ten-vars 13.2291+-1.0406 12.8459+-0.9171 might be 1.0298x faster infer-one-time-closure-two-vars 12.0669+-0.3393 ? 12.7440+-1.3240 ? might be 1.0561x slower infer-one-time-closure 12.3604+-0.4168 ? 12.8422+-1.2639 ? might be 1.0390x slower infer-one-time-deep-closure 21.7063+-1.2946 21.2054+-1.0019 might be 1.0236x faster inline-arguments-access 5.0096+-0.6776 4.6694+-0.0627 might be 1.0729x faster inline-arguments-aliased-access 4.8414+-0.3526 4.6692+-0.0552 might be 1.0369x faster inline-arguments-local-escape 4.7723+-0.1471 4.7703+-0.2429 inline-get-scoped-var 4.9910+-0.2773 ? 5.1343+-0.3683 ? might be 1.0287x slower inlined-put-by-id-transition 11.8484+-0.4379 11.8181+-0.4799 int-or-other-abs-then-get-by-val 5.0133+-0.0716 ? 5.0515+-0.1304 ? int-or-other-abs-zero-then-get-by-val 17.7474+-0.9941 17.6337+-0.4970 int-or-other-add-then-get-by-val 4.4097+-0.0787 ? 4.5315+-0.4379 ? might be 1.0276x slower int-or-other-add 5.5052+-0.1663 5.4724+-0.1995 int-or-other-div-then-get-by-val 4.2903+-0.0318 ? 4.3975+-0.1859 ? might be 1.0250x slower int-or-other-max-then-get-by-val 4.4191+-0.1271 4.3694+-0.0881 might be 1.0114x faster int-or-other-min-then-get-by-val 4.3749+-0.0757 4.3540+-0.0438 int-or-other-mod-then-get-by-val 3.9631+-0.0826 ? 4.0028+-0.1254 ? might be 1.0100x slower int-or-other-mul-then-get-by-val 3.9622+-0.0516 ? 4.0303+-0.1900 ? might be 1.0172x slower int-or-other-neg-then-get-by-val 4.8656+-0.0848 4.7885+-0.0298 might be 1.0161x faster int-or-other-neg-zero-then-get-by-val 18.2415+-0.6753 ? 18.6864+-0.9009 ? might be 1.0244x slower int-or-other-sub-then-get-by-val 4.4045+-0.0417 4.3991+-0.0763 int-or-other-sub 3.9119+-0.4209 3.6916+-0.0864 might be 1.0597x faster int-overflow-local 4.7029+-0.1972 4.6429+-0.2282 might be 1.0129x faster Int16Array-alloc-long-lived 53.6401+-2.0327 52.9918+-1.8406 might be 1.0122x faster Int16Array-bubble-sort-with-byteLength 20.3352+-0.7253 20.3263+-0.7909 Int16Array-bubble-sort 20.9904+-1.4695 20.7103+-0.6193 might be 1.0135x faster Int16Array-load-int-mul 1.6446+-0.1973 1.5525+-0.0459 might be 1.0593x faster Int16Array-to-Int32Array-set 58.0521+-1.4255 ^ 54.5826+-1.9112 ^ definitely 1.0636x faster Int32Array-alloc-large 23.5260+-0.6622 ? 24.3186+-1.6381 ? might be 1.0337x slower Int32Array-alloc-long-lived 63.9761+-1.0218 ? 64.6050+-0.6842 ? Int32Array-alloc 3.5107+-0.2775 3.4315+-0.0521 might be 1.0231x faster Int32Array-Int8Array-view-alloc 6.8626+-0.2167 ? 7.8508+-2.2408 ? might be 1.1440x slower int52-spill 5.8182+-0.1166 5.7662+-0.1564 Int8Array-alloc-long-lived 48.7320+-1.9451 ? 49.5735+-0.3191 ? might be 1.0173x slower Int8Array-load-with-byteLength 3.4141+-0.0547 ? 3.6268+-0.4459 ? might be 1.0623x slower Int8Array-load 3.9264+-0.4856 3.5484+-0.4019 might be 1.1065x faster integer-divide 10.9251+-0.0779 ? 10.9679+-0.1299 ? integer-modulo 2.3058+-0.2905 2.1050+-0.0724 might be 1.0954x faster is-boolean-fold-tricky 4.5074+-0.1120 ? 4.6405+-0.5217 ? might be 1.0295x slower is-boolean-fold 2.8925+-0.0421 2.8910+-0.0561 is-function-fold-tricky-internal-function 12.1363+-0.4721 11.7588+-0.1012 might be 1.0321x faster is-function-fold-tricky 4.7861+-0.4313 4.5869+-0.0944 might be 1.0434x faster is-function-fold 2.9915+-0.0814 2.9571+-0.0672 might be 1.0117x faster is-number-fold-tricky 4.7229+-0.5645 4.5131+-0.0727 might be 1.0465x faster is-number-fold 2.9056+-0.0579 ? 2.9970+-0.2070 ? might be 1.0315x slower is-object-or-null-fold-functions 3.0999+-0.1690 3.0916+-0.3601 is-object-or-null-fold-less-tricky 4.7891+-0.3103 4.5990+-0.1067 might be 1.0413x faster is-object-or-null-fold-tricky 6.7646+-0.1303 6.6744+-0.0926 might be 1.0135x faster is-object-or-null-fold 2.9364+-0.0615 ? 3.0175+-0.1886 ? might be 1.0276x slower is-object-or-null-trickier-function 4.8338+-0.1815 ? 4.9655+-0.6109 ? might be 1.0272x slower is-object-or-null-trickier-internal-function 12.4110+-0.1194 12.3937+-0.0733 is-object-or-null-tricky-function 4.6174+-0.0874 ? 4.7801+-0.2581 ? might be 1.0352x slower is-object-or-null-tricky-internal-function 9.3198+-0.0877 9.3159+-0.1132 is-string-fold-tricky 4.5444+-0.1354 ? 4.8885+-0.4509 ? might be 1.0757x slower is-string-fold 2.9506+-0.1473 ? 2.9712+-0.2620 ? is-undefined-fold-tricky 3.7465+-0.0399 ? 3.8036+-0.0601 ? might be 1.0152x slower is-undefined-fold 3.0174+-0.2315 2.9947+-0.2924 large-int-captured 4.9521+-0.0880 4.8966+-0.1299 might be 1.0113x faster large-int-neg 16.5185+-1.0041 16.2873+-0.4356 might be 1.0142x faster large-int 14.7549+-0.4576 ? 14.9762+-0.4066 ? might be 1.0150x slower load-varargs-elimination 22.8980+-0.3078 ? 23.7988+-1.3655 ? might be 1.0393x slower logical-not-weird-types 3.3936+-0.0237 ? 3.5672+-0.3781 ? might be 1.0511x slower logical-not 4.6740+-0.0198 ? 4.8042+-0.1560 ? might be 1.0279x slower lots-of-fields 12.7179+-0.7427 12.1534+-0.1420 might be 1.0464x faster make-indexed-storage 3.3097+-0.1025 3.3097+-0.1983 make-rope-cse 13.0005+-1.3301 12.2858+-1.5559 might be 1.0582x faster marsaglia-larger-ints 36.6676+-0.7556 ? 37.4895+-1.4773 ? might be 1.0224x slower marsaglia-osr-entry 23.2181+-0.9723 ? 24.0225+-1.5444 ? might be 1.0346x slower math-with-out-of-bounds-array-values 25.4114+-1.1494 ? 25.4931+-1.5525 ? max-boolean 2.6758+-0.3145 2.5130+-0.0293 might be 1.0648x faster method-on-number 17.9859+-0.6444 ? 19.0315+-0.9539 ? might be 1.0581x slower min-boolean 2.5653+-0.0980 ? 2.7703+-0.3775 ? might be 1.0799x slower minus-boolean-double 3.3456+-0.2797 3.2171+-0.0653 might be 1.0400x faster minus-boolean 2.5597+-0.2769 2.5028+-0.2855 might be 1.0227x faster misc-strict-eq 41.0668+-5.8039 38.0527+-0.5467 might be 1.0792x faster mod-boolean-double 11.1704+-0.4619 10.9989+-0.1570 might be 1.0156x faster mod-boolean 7.8923+-0.0331 ? 8.0937+-0.2766 ? might be 1.0255x slower mul-boolean-double 3.8723+-0.3476 3.8647+-0.1807 mul-boolean 3.0049+-0.2775 2.9480+-0.0426 might be 1.0193x faster neg-boolean 3.2545+-0.0784 ? 3.2915+-0.1734 ? might be 1.0114x slower negative-zero-divide 0.4167+-0.0416 0.3849+-0.0135 might be 1.0827x faster negative-zero-modulo 0.4042+-0.0351 ? 0.4453+-0.0424 ? might be 1.1017x slower negative-zero-negate 0.3867+-0.0353 ? 0.4021+-0.0526 ? might be 1.0400x slower nested-function-parsing 39.7114+-1.2322 ? 39.9244+-1.2405 ? new-array-buffer-dead 113.3550+-2.4389 113.0735+-1.6879 new-array-buffer-push 7.2833+-0.6878 ? 7.3370+-0.6384 ? new-array-dead 20.0577+-0.9805 19.9032+-1.1354 new-array-push 6.5542+-0.1692 ? 6.6046+-0.2462 ? no-inline-constructor 42.3860+-0.9909 41.7125+-0.9925 might be 1.0161x faster number-test 3.2441+-0.2985 ? 3.2539+-0.2733 ? object-closure-call 5.6760+-0.0625 ? 6.0106+-0.6846 ? might be 1.0589x slower object-test 2.9878+-0.1964 2.9071+-0.0602 might be 1.0278x faster obvious-sink-pathology-taken 142.5278+-2.0688 ? 142.9125+-2.8109 ? obvious-sink-pathology 132.3582+-2.6706 ? 133.4755+-2.3593 ? obviously-elidable-new-object 37.1518+-3.2908 34.6395+-0.4698 might be 1.0725x faster plus-boolean-arith 2.7072+-0.3261 2.6479+-0.1647 might be 1.0224x faster plus-boolean-double 3.2952+-0.1373 3.2795+-0.1074 plus-boolean 2.4724+-0.1083 2.4576+-0.0756 poly-chain-access-different-prototypes-simple 3.3319+-0.0563 ? 3.4477+-0.3690 ? might be 1.0348x slower poly-chain-access-different-prototypes 2.7330+-0.3133 2.6183+-0.0246 might be 1.0438x faster poly-chain-access-simpler 3.4047+-0.1360 3.3668+-0.0699 might be 1.0113x faster poly-chain-access 2.6913+-0.1050 ? 2.7463+-0.3154 ? might be 1.0204x slower poly-stricteq 64.4800+-2.1431 62.3552+-0.6170 might be 1.0341x faster polymorphic-array-call 1.3929+-0.0355 ? 1.4465+-0.1111 ? might be 1.0384x slower polymorphic-get-by-id 3.2911+-0.1556 ? 3.3894+-0.2967 ? might be 1.0299x slower polymorphic-put-by-id 32.7212+-3.7259 30.7568+-1.8773 might be 1.0639x faster polymorphic-structure 15.8531+-1.3805 15.5669+-1.0791 might be 1.0184x faster polyvariant-monomorphic-get-by-id 8.5969+-0.1151 ? 8.9930+-0.5324 ? might be 1.0461x slower proto-getter-access 9.3920+-0.1773 ? 9.3931+-0.1185 ? put-by-id-replace-and-transition 9.9880+-0.6587 9.7309+-0.2145 might be 1.0264x faster put-by-id-slightly-polymorphic 2.8557+-0.0333 2.8434+-0.0184 put-by-id 12.8522+-0.2451 ? 12.9682+-0.4048 ? put-by-val-direct 0.4438+-0.0602 ? 0.4496+-0.1124 ? might be 1.0131x slower put-by-val-large-index-blank-indexing-type 12.4135+-1.1070 ? 12.5429+-1.4810 ? might be 1.0104x slower put-by-val-machine-int 2.9025+-0.0877 2.8631+-0.0589 might be 1.0138x faster rare-osr-exit-on-local 15.3892+-0.8918 15.0562+-0.3774 might be 1.0221x faster register-pressure-from-osr 22.2969+-1.1054 21.8652+-1.0931 might be 1.0197x faster repeat-multi-get-by-offset 24.9307+-0.7400 24.6195+-0.1725 might be 1.0126x faster setter-prototype 10.5666+-0.2624 10.5648+-0.2953 setter 5.7303+-0.7680 ? 6.3505+-0.8466 ? might be 1.1082x slower simple-activation-demo 25.6131+-0.7623 25.4016+-0.6236 simple-getter-access 11.9830+-0.3254 11.7417+-0.2313 might be 1.0205x faster simple-poly-call-nested 8.4688+-0.9278 ? 8.5124+-0.3311 ? simple-poly-call 1.3260+-0.0258 ? 1.3269+-0.0467 ? sin-boolean 23.0092+-1.1912 ? 23.3223+-1.0133 ? might be 1.0136x slower singleton-scope 62.3020+-0.9558 61.7810+-0.6363 sink-function 12.4285+-0.9190 12.1387+-0.2871 might be 1.0239x faster sink-huge-activation 20.3552+-1.7253 19.6976+-0.8876 might be 1.0334x faster sinkable-new-object-dag 71.7255+-2.7672 69.8969+-1.8405 might be 1.0262x faster sinkable-new-object-taken 51.2249+-3.3976 50.6859+-2.7825 might be 1.0106x faster sinkable-new-object 39.5233+-1.0839 ? 41.2115+-3.6710 ? might be 1.0427x slower slow-array-profile-convergence 3.0177+-0.0971 ? 3.0555+-0.3643 ? might be 1.0125x slower slow-convergence 2.9187+-0.3555 ? 2.9672+-0.4235 ? might be 1.0166x slower slow-ternaries 21.6601+-3.6756 21.1895+-2.5571 might be 1.0222x faster sorting-benchmark 18.8253+-0.5517 ? 19.2882+-0.5913 ? might be 1.0246x slower sparse-conditional 1.1679+-0.0204 ? 1.2270+-0.0708 ? might be 1.0506x slower splice-to-remove 15.6229+-0.9510 ? 15.8502+-1.3496 ? might be 1.0145x slower string-char-code-at 18.4179+-0.1285 ^ 16.5096+-0.5827 ^ definitely 1.1156x faster string-concat-object 2.7349+-0.2900 ? 2.7576+-0.2231 ? string-concat-pair-object 2.6905+-0.2391 ? 2.6996+-0.1957 ? string-concat-pair-simple 11.7960+-0.4949 ? 12.2258+-1.2118 ? might be 1.0364x slower string-concat-simple 12.4346+-0.9646 12.4208+-1.1704 string-cons-repeat 8.3590+-0.9899 8.1318+-0.4683 might be 1.0279x faster string-cons-tower 8.5588+-0.4869 8.2474+-0.3040 might be 1.0378x faster string-equality 17.8814+-0.1920 ? 18.0708+-0.5400 ? might be 1.0106x slower string-get-by-val-big-char 7.3714+-0.1336 7.2603+-0.0488 might be 1.0153x faster string-get-by-val-out-of-bounds-insane 3.6827+-0.1736 3.6766+-0.2041 string-get-by-val-out-of-bounds 5.4482+-0.1264 5.4121+-0.0963 string-get-by-val 3.4799+-0.0630 3.4478+-0.0187 string-hash 2.5581+-0.6408 2.2007+-0.1078 might be 1.1624x faster string-long-ident-equality 14.9967+-0.1613 ? 15.3324+-1.1821 ? might be 1.0224x slower string-out-of-bounds 15.0730+-0.3874 ? 15.2620+-0.8009 ? might be 1.0125x slower string-repeat-arith 34.7466+-1.9024 ? 35.4045+-2.0187 ? might be 1.0189x slower string-sub 66.4457+-4.0555 63.6180+-2.0203 might be 1.0444x faster string-test 3.0701+-0.1464 ? 3.2814+-0.3691 ? might be 1.0688x slower string-var-equality 35.6313+-1.2027 34.4493+-0.4713 might be 1.0343x faster structure-hoist-over-transitions 2.7623+-0.1404 ? 2.8167+-0.2406 ? might be 1.0197x slower substring-concat-weird 46.2624+-6.2329 42.7163+-1.6373 might be 1.0830x faster substring-concat 45.3662+-0.5974 45.3566+-1.0569 substring 49.1640+-1.3968 ? 49.7642+-1.4507 ? might be 1.0122x slower switch-char-constant 2.8826+-0.1569 ? 2.9658+-0.2142 ? might be 1.0288x slower switch-char 6.7598+-0.7396 ? 6.9812+-1.4313 ? might be 1.0327x slower switch-constant 8.4552+-0.1886 ? 8.5765+-0.2114 ? might be 1.0143x slower switch-string-basic-big-var 18.4473+-0.4643 18.2308+-0.2909 might be 1.0119x faster switch-string-basic-big 15.2839+-0.1936 15.2373+-0.2888 switch-string-basic-var 15.2655+-0.2335 15.2538+-0.3069 switch-string-basic 14.3184+-0.6364 13.7689+-0.1303 might be 1.0399x faster switch-string-big-length-tower-var 20.7455+-1.1375 20.5647+-0.1682 switch-string-length-tower-var 15.2953+-0.1701 ? 15.5288+-0.3204 ? might be 1.0153x slower switch-string-length-tower 13.5295+-0.9517 13.1297+-0.1271 might be 1.0304x faster switch-string-short 13.2319+-0.1601 13.1533+-0.1806 switch 12.8947+-0.5134 12.6213+-0.2242 might be 1.0217x faster tear-off-arguments-simple 3.6190+-0.1177 3.5153+-0.0965 might be 1.0295x faster tear-off-arguments 4.8798+-0.1771 ? 5.1623+-0.8191 ? might be 1.0579x slower temporal-structure 12.3849+-0.2125 12.3272+-0.2220 to-int32-boolean 14.3859+-0.9917 14.0723+-0.1481 might be 1.0223x faster try-catch-get-by-val-cloned-arguments 15.7135+-1.8378 ? 15.9762+-1.6367 ? might be 1.0167x slower try-catch-get-by-val-direct-arguments 6.9626+-0.5344 ? 7.5288+-0.9644 ? might be 1.0813x slower try-catch-get-by-val-scoped-arguments 7.6732+-0.1095 ! 8.2320+-0.3856 ! definitely 1.0728x slower typed-array-get-set-by-val-profiling 33.4799+-0.9323 29.8670+-2.9144 might be 1.1210x faster undefined-property-access 346.9084+-8.7213 343.0378+-2.8125 might be 1.0113x faster undefined-test 3.1431+-0.1237 3.0842+-0.0446 might be 1.0191x faster unprofiled-licm 22.6274+-0.4465 ? 22.8323+-0.5741 ? varargs-call 15.7485+-1.3552 15.4881+-0.7854 might be 1.0168x faster varargs-construct-inline 28.4900+-0.6379 28.0432+-0.4427 might be 1.0159x faster varargs-construct 22.9314+-1.2072 22.8966+-0.5234 varargs-inline 9.3843+-0.0912 ? 9.5475+-0.2397 ? might be 1.0174x slower varargs-strict-mode 10.6836+-1.2587 10.6563+-1.2309 varargs 10.3165+-0.4105 10.0305+-0.1037 might be 1.0285x faster weird-inlining-const-prop 3.5450+-0.3155 3.4519+-0.2207 might be 1.0270x faster <geometric> 9.2278+-0.0315 ^ 9.1484+-0.0324 ^ definitely 1.0087x faster TipOfTree ABC AsmBench: bigfib.cpp 500.0259+-2.0519 ? 502.4072+-3.0858 ? cray.c 426.9934+-1.3342 ! 432.4208+-2.4383 ! definitely 1.0127x slower dry.c 491.8765+-3.9801 ? 500.0514+-26.6401 ? might be 1.0166x slower FloatMM.c 721.0229+-1.4392 ? 722.8960+-2.2162 ? gcc-loops.cpp 4102.5776+-15.5565 ? 4159.7092+-180.4979 ? might be 1.0139x slower n-body.c 973.5851+-4.5731 ? 974.2305+-6.5683 ? Quicksort.c 424.0225+-5.5440 ? 428.2373+-13.3896 ? stepanov_container.cpp 3614.4546+-14.0813 3603.5605+-30.5310 Towers.c 256.9250+-2.2223 ? 263.0252+-13.0089 ? might be 1.0237x slower <geometric> 789.4308+-1.2350 ? 796.3984+-11.2864 ? might be 1.0088x slower TipOfTree ABC CompressionBench: huffman 373.7850+-3.0668 ^ 349.3406+-2.3634 ^ definitely 1.0700x faster arithmetic-simple 369.0642+-9.8230 ^ 337.8705+-2.8123 ^ definitely 1.0923x faster arithmetic-precise 285.2642+-2.9885 ^ 276.2625+-2.5717 ^ definitely 1.0326x faster arithmetic-complex-precise 286.0733+-3.3122 ^ 273.4120+-2.9124 ^ definitely 1.0463x faster arithmetic-precise-order-0 378.1238+-3.1771 353.2037+-22.9201 might be 1.0706x faster arithmetic-precise-order-1 335.6805+-5.1630 331.3655+-4.5926 might be 1.0130x faster arithmetic-precise-order-2 372.7848+-19.6185 371.1562+-3.8474 arithmetic-simple-order-1 428.7566+-3.7687 ^ 405.5364+-10.3436 ^ definitely 1.0573x faster arithmetic-simple-order-2 484.8106+-23.7478 ^ 444.6417+-5.7557 ^ definitely 1.0903x faster lz-string 317.0408+-3.7909 ? 325.8456+-6.6934 ? might be 1.0278x slower <geometric> 358.4650+-3.5872 ^ 343.2589+-2.5697 ^ definitely 1.0443x faster TipOfTree ABC Geomean of preferred means: <scaled-result> 62.5019+-0.1965 62.0662+-0.4398 might be 1.0070x faster
Created attachment 254993 [details] getting ready for landing
Attachment 254993 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:329: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:894: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:894: Multi line control clauses should use braces. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1169: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1218: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 5 in 22 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 254995 [details] closer to landing
Attachment 254995 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:927: Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side. [whitespace/operators] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:927: Multi line control clauses should use braces. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1202: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 3 in 22 files If any of these errors are false positives, please file a bug against check-webkit-style.
(In reply to comment #26) > (In reply to comment #25) > > Comment on attachment 254964 [details] > > the patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=254964&action=review > > > > > Source/JavaScriptCore/ChangeLog:35 > > > + * tests/stress/add-overflows-after-not-equal.js: Added. > > > + * tests/stress/sub-overflows-after-not-equal.js: Added. > > > > IMHO, it would be worth adding stress tests to check anything you can come > > up with. > > > > It's not exactly a simple patch and we'll have very little time to discover > > any unforeseen side effect. > > Agreed. I'll try to come up with more tests. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:714 > > > + bool changed = true; > > > + while (changed) { > > > > I think it would be good to explain the convergency trick on < and > with 1, > > 0, -1 that you explained in your office. Otherwise it seems a bit mysterious > > that this does not run forever. > > OK. I will try to say something about this. The latest version simplifies this code and has a long discussion of convergence. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1137 > > > + if (m_seenBlocks.add(target)) { > > > > What is inside the if() is pretty self contained. If it is possible to move > > it to a function, that may make the code more readable. > > > > Maybe: > > filterLiveRelationships(relationshipMap, target, [] (Node* node, const > > Vector<Relationship>& liveRelationships) > > ? > > I'll try that. I don't think this is so necessary anymore, because that code no longer involves that ugly functor. > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1170 > > > + // are using RPO. > > > > RPO -> reverse post-order traversal. I am not good at remembering acronyms :) > > OK! > > > > > > Source/JavaScriptCore/dfg/DFGIntegerRangeOptimizationPhase.cpp:1181 > > > + Vector<Relationship> values; > > > > values->mergedRelationships or something like that? > > OK.
Landed in http://trac.webkit.org/changeset/185640
32-bit build fix in http://trac.webkit.org/changeset/185646 Also, why doesn't 64-bit JSC compile with -Wshorten-64-to-32 ?
Looks like this was 2% progresssion on Kraken according to our internal testing.