/
ChangeLog
16896 lines (13863 loc) · 740 KB
/
ChangeLog
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
2021-08-09 Michael Catanzaro <mcatanzaro@gnome.org>
Adding missing REFERENCED_FROM_ASM annotations to facilitate LTO
https://bugs.webkit.org/show_bug.cgi?id=228865
Reviewed by Yusuke Suzuki.
When investigating why WebKitGTK fails to build with LTO (link-time optimization) enabled,
one of the GCC developers noticed that we are missing __attribute__ (("used")) on several
C++ functions declared in LLIntSlowPaths.h and WasmSlowPaths.h that are called only from
asm. Without this attribute, GCC assumes the functions are unused and drops them, then
linking fails because they really are used.
* llint/LLIntSlowPaths.h:
* wasm/WasmSlowPaths.h:
2021-08-07 Michael Catanzaro <mcatanzaro@gnome.org>
Fix ODR violations in JSC
https://bugs.webkit.org/show_bug.cgi?id=228876
Reviewed by Yusuke Suzuki.
When built with LTO enabled, GCC will warn about violations of C++'s one-definition rule.
JSC currently has two violations. The first is JSC::SpeciesConstructResult, which has two
different declarations, one in ArrayPrototype.cpp and the other in
JSArrayBufferPrototype.cpp. I decided to change the version in ArrayPrototype.cpp to make
the declarations match.
The next problem is JSC::SignalContext. We have two different versions of this struct, one
in VMTraps.cpp and the other in SigillCrashAnalyzer.cpp. In this case, I decided to change
the one in VMTraps.cpp from JSC::SignalContext to JSC::VMTraps::SignalContext.
* runtime/ArrayPrototype.cpp:
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
* runtime/VMTraps.h:
2021-08-07 Keith Miller <keith_miller@apple.com>
for-in should only emit one loop in bytecode
https://bugs.webkit.org/show_bug.cgi?id=227989
Reviewed by Yusuke Suzuki.
This patch redesigns how we implement for-in loops. Before this patch we would emit three copies of the for-in loop body. One for the indexed properties, one for the named-own properties, and one for generic properties (anything else). This had a couple of problems. Firstly, it meant bytecode size grew exponentially to number of nested for-in loops. This in turn meant DFG/FTL compilation took much longer.
Going off our experience with fast for-of, this patch turns for-in loops specializations into
a "fused" opcode that internally switches on the enumeration mode it currently sees. For example, if we are enumerating an own-named property, the new enumerator_get_by_val bytecode will check the enumerator cell's cached structure matches the base's then load the property offset directly.
There are four new opcodes this patch adds, which replace the various operations we had for the specialized loops previously. The new opcodes are EnumeratorGetByVal, EnumeratorInByVal, EnumeratorHasOwnProperty, and EnumeratorNext. The first three correspond to GetByVal, InByVal, and HasOwnProperty respectively. The EnumeratorNext opcode has three results in bytecode, the next enumeration value's mode, the index of the property name, and the property name string itself. When enumeration is done EnumeratorNext returns JS null as the property name string. Since the DFG doesn't support tuples yet this opcode is spilt into four new nodes. The first computes the updated index and mode for the next enumeration key, which is encoded into a single JS number. Then there are two nodes that extract the mode and index. Finally, the last new node produces the property name string or null based on the extracted mode and index.
Since, in most benchmarks, any given enumeration opcode tends to profile exactly one enumeration mode. This patch focuses primarily on reimplementing all the optimizations we have for any one specific mode. This means there are still potential optimizations for the multi-mode flavors of each new opcode.
The main optimizations implemented for each new opcode are:
EnumeratorNext:
1) IndexedMode loops are loaded and checked for presence inline (DFG/FTL).
2) NamedMode is computed inline as long as the cached structure on the enumerator cell matches the base (Baseline+). This can only differ if there's a transition.
3) property names are extracted from the cached buffer inline (Baseline+).
EnumeratorGetByVal:
EnumeratorInByVal:
EnumeratorHasOwnProperty:
1) IndexedMode has all the optimizations of a normal XByVal on indexed properties (DFG/FTL).
2) NamedMode will extract the value directly from the inline/out-of-line offset if the structure matches the enumerator's (Baseline+).
There are also a few interesting changes worth mentioning here:
1) If a for-in loop would produce an empty enumerator we now always
return the VMs empty enumerator. This has two benefits, most importantly, it distingishes between an unprofiled for-in loop and empty enumeration, which prevents OSR exit loops. Also, it means that the various Enumerator opcodes no longer need to handle undefined/null when `toObject`ing the base value.
2) The enumerator now contains a bit set of all the modes it will produce. This removes a few extra branches when speculating on the modes we will see in EnumeratorNext.
3) In the DFG, enumerator GetByVal relies on compileGetByVal to set the result it also passes a prefix callback which emits code after the various cases set up their operands but before code is emitting to help satisfy the branch over register allocation validation. Also, the array mode branch in compileGetByVal passes the data format that it would prefer, which for normal GetByVal is returned. For EnumeratorGetByVal, that preference is completely ignored and it always returns DataFormatJS.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::or8):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::or8):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::rshift64):
(JSC::MacroAssemblerX86_64::or8): Deleted.
* builtins/BuiltinNames.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/LinkTimeConstant.h:
* bytecode/Opcode.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::recordHasOwnPropertyInForInLoop):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitEnumeratorNext):
(JSC::BytecodeGenerator::emitEnumeratorHasOwnProperty):
(JSC::BytecodeGenerator::pushForInScope):
(JSC::BytecodeGenerator::popForInScope):
(JSC::rewriteOp):
(JSC::ForInContext::finalize):
(JSC::BytecodeGenerator::findForInContext):
(JSC::BytecodeGenerator::recordHasOwnStructurePropertyInForInLoop): Deleted.
(JSC::BytecodeGenerator::emitGetEnumerableLength): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableIndexedProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableProperty): Deleted.
(JSC::BytecodeGenerator::emitHasOwnStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName): Deleted.
(JSC::BytecodeGenerator::emitToIndexString): Deleted.
(JSC::BytecodeGenerator::pushIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::popIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::pushStructureForInScope): Deleted.
(JSC::BytecodeGenerator::popStructureForInScope): Deleted.
(JSC::StructureForInContext::finalize): Deleted.
(JSC::IndexedForInContext::finalize): Deleted.
(JSC::BytecodeGenerator::findStructureForInContext): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::ForInContext::isValid const):
(JSC::ForInContext::invalidate):
(JSC::ForInContext::local const):
(JSC::ForInContext::propertyName const):
(JSC::ForInContext::propertyOffset const):
(JSC::ForInContext::enumerator const):
(JSC::ForInContext::mode const):
(JSC::ForInContext::ForInContext):
(JSC::ForInContext::bodyBytecodeStartOffset const):
(JSC::ForInContext::type const): Deleted.
(JSC::ForInContext::isIndexedForInContext const): Deleted.
(JSC::ForInContext::isStructureForInContext const): Deleted.
(JSC::ForInContext::asIndexedForInContext): Deleted.
(JSC::ForInContext::asStructureForInContext): Deleted.
(JSC::StructureForInContext::StructureForInContext): Deleted.
(JSC::StructureForInContext::index const): Deleted.
(JSC::StructureForInContext::property const): Deleted.
(JSC::StructureForInContext::enumerator const): Deleted.
(JSC::StructureForInContext::baseVariable const): Deleted.
(JSC::StructureForInContext::addGetInst): Deleted.
(JSC::StructureForInContext::addInInst): Deleted.
(JSC::StructureForInContext::addHasOwnPropertyJump): Deleted.
(JSC::IndexedForInContext::IndexedForInContext): Deleted.
(JSC::IndexedForInContext::index const): Deleted.
(JSC::IndexedForInContext::addGetInst): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isSaneChain const):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::injectOSR):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::setJSArraySaneChainIfPossible):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasStorageChild const):
(JSC::DFG::Node::storageChildIndex):
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::hasEnumeratorMetadata const):
(JSC::DFG::Node::enumeratorMetadata):
* dfg/DFGNodeType.h:
* dfg/DFGOpInfo.h:
(JSC::DFG::OpInfo::OpInfo):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::handleNode):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol):
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractIndex):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName):
(JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty):
(JSC::DFG::SpeculativeJIT::compileEnumeratorInByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasOwnProperty):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
(JSC::DFG::SpeculativeJIT::compileGetEnumerableLength): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileToIndexString): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructurePropertyImpl): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileInStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetEnumeratorPname): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetDirectPname): Deleted.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::allocate):
(JSC::DFG::JSValueOperand::regs):
(JSC::DFG::JSValueOperand::gpr):
(JSC::DFG::StorageOperand::StorageOperand):
(JSC::DFG::StorageOperand::~StorageOperand):
(JSC::DFG::StorageOperand::emplace):
(JSC::DFG::JSValueRegsTemporary::operator bool):
(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByVal):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByVal):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByValImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAtImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
* ftl/FTLOutput.h:
(JSC::FTL::Output::phi):
* generator/DSL.rb:
* interpreter/Register.h:
* interpreter/RegisterInlines.h:
(JSC::Register::operator=):
* jit/AssemblyHelpers.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::generateGetByValSlowCase):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_enumerator_has_propertyImpl):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/CommonSlowPaths.h:
* runtime/FileBasedFuzzerAgent.cpp:
(JSC::FileBasedFuzzerAgent::getPredictionInternal):
* runtime/FileBasedFuzzerAgentBase.cpp:
(JSC::FileBasedFuzzerAgentBase::opcodeAliasForLookupKey):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
(JSC::JSPropertyNameEnumerator::computeNext):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/PredictionFileCreatingFuzzerAgent.cpp:
(JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal):
2021-08-06 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix on Debug build
https://bugs.webkit.org/show_bug.cgi?id=228810
* yarr/YarrJIT.h:
(JSC::Yarr::BoyerMooreBitmap::addCharacters):
(JSC::Yarr::BoyerMooreBitmap::addRanges):
2021-08-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Yarr's character tracking for BoyerMoore search should be more precise
https://bugs.webkit.org/show_bug.cgi?id=228810
Reviewed by Saam Barati.
We should track up to 2 candidate characters without masking, so
that we can search a character without masking. To track candidates,
we introduce BoyerMooreCharacterCandidates.
We also add support for m_table because m_table can be used
for important CharacterClass like `\s`, and still that does not have
many character candidates if the mode is Char8.
To make `\s` work on Char8 case, we use Char8 / Char16 information
to filter characters that never appears in BoyreMoore search bitmap
construction.
* yarr/YarrJIT.cpp:
(JSC::Yarr::BoyerMooreInfo::BoyerMooreInfo):
(JSC::Yarr::BoyerMooreInfo::set):
(JSC::Yarr::BoyerMooreInfo::addCharacters):
(JSC::Yarr::BoyerMooreInfo::addRanges):
(JSC::Yarr::BoyerMooreInfo::create):
(JSC::Yarr::BoyerMooreInfo::createCandidateBitmap const):
* yarr/YarrJIT.h:
(JSC::Yarr::BoyerMooreCharacterCandidates::isValid const):
(JSC::Yarr::BoyerMooreCharacterCandidates::invalidate):
(JSC::Yarr::BoyerMooreCharacterCandidates::isEmpty const):
(JSC::Yarr::BoyerMooreCharacterCandidates::size const):
(JSC::Yarr::BoyerMooreCharacterCandidates::at const):
(JSC::Yarr::BoyerMooreCharacterCandidates::add):
(JSC::Yarr::BoyerMooreCharacterCandidates::merge):
(JSC::Yarr::BoyerMooreBitmap::characterCandidates const):
(JSC::Yarr::BoyerMooreBitmap::add):
(JSC::Yarr::BoyerMooreBitmap::addCharacters):
(JSC::Yarr::BoyerMooreBitmap::addRanges):
(JSC::Yarr::BoyerMooreBitmap::isMaskEffective const): Deleted.
2021-08-05 Mikhail R. Gadelha <mikhail@igalia.com>
Assertion failure when checking array in DFG (32 bits)
https://bugs.webkit.org/show_bug.cgi?id=228839
Reviewed by Yusuke Suzuki.
Since empty values don't pass the cell check in 32 bits, we need to
guard the SpecEmpty check to only happen in 64 bits archs
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
2021-08-05 Robin Morisset <rmorisset@apple.com>
REGRESSION (r280507): ASSERTION FAILED: !undominatedPhis.contains(value) in JSC::B3::(anonymous namespace)::Validater::validatePhisAreDominatedByUpsilons()
https://bugs.webkit.org/show_bug.cgi?id=228838
<rdar://problem/81579314>
Reviewed by Geoffrey Garen.
When I added validation of the dominance of Phis by their Upsilons, I checked two things:
- There is no path from the entry point to a Phi without going through a corresponding Upsilon (the actual dominance check)
- There is no way to execute a Phi twice without going through a corresponding Upsilon in between
The second property is not actually true in B3 IR, I had misunderstood that part of the meaning of Phis/Upsilons.
So this patch just removes this second check.
It has no security/stability/performance implication: this is validation code, which runs automatically in debug mode, but should not run at all on customer machines.
* b3/B3Validate.cpp:
2021-08-05 Michael Catanzaro <mcatanzaro@gnome.org>
GCC 11 builds should use -Wno-array-bounds, -Wno-nonnull
https://bugs.webkit.org/show_bug.cgi?id=228601
Reviewed by Carlos Garcia Campos.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
2021-08-05 Zan Dobersek <zdobersek@igalia.com>
Use reinterpret_cast_ptr in KeywordLookupGenerator, PropertyMapHashTable
https://bugs.webkit.org/show_bug.cgi?id=228819
Reviewed by Adrian Perez de Castro.
Switch to using reinterpret_cast_ptr in KeywordLookupGenerator (which
generates the KeywordLookup.h header) and PropertyMapHashTable, reducing
a bit the GCC warning spewage when compiling for targets benefitting
from the reinterpret_cast_ptr workaround.
* KeywordLookupGenerator.py:
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::table):
(JSC::PropertyTable::table const):
2021-08-04 Yijia Huang <yijia_huang@apple.com>
[ARM64] Fix Zoom black screen during video meeting on Safari
https://bugs.webkit.org/show_bug.cgi?id=228776
Reviewed by Saam Barati.
The problem (rdar://81434487) reports that Zoom turns to a black screen during the video
meeting on Safari. The reproduction of this problem is verified and bisected to the previous patch
(https://bugs.webkit.org/show_bug.cgi?id=228057). Previously, we introduce a pattern
matching for instruction EON-with-shift on ARM64, where the pattern is d = n ^ ((m ShiftType amount) ^ -1).
x = m ShiftType amount
y = x ^ -1
z = n ^ y
We check canBeInternal() on x but not on y based on the computing cost analysis in that patch,
which is totally wrong. If the pattern matching is triggered, then the compiler would not emit
the corresponding Air of x after lowering, leading to data corruption or system crash since y
depends on x.
In the real world example (Zoom video meeting), we find the B3 IR:
...
Int32 b@528 = SShr(b@526, $31(b@527), Wasm: {opcode: I32ShrS, location: 0x26b})
Int32 b@529 = BitXor(b@528, $-1(b@144), Wasm: {opcode: I32Xor, location: 0x26e})
...
Int32 b@551 = BitXor(b@446, b@529, Wasm: {opcode: I32Xor, location: 0x28e})
...
After Lowering to Air:
...
Not32 %fp, %x2, b@529
...
XorNotRightShift32 %tmp199, %tmp211, $31, %tmp209, b@551
...
Since the implementation of the previous patch does commitInternal() on b@528, the operand of
b@529 turns to a frame pointer. To resolve this problem, we should either check canBeInternal()
on both b@528 and b@529 or not at all.
* b3/B3LowerToAir.cpp:
2021-08-04 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r280609.
https://bugs.webkit.org/show_bug.cgi?id=228791
Broke JSC tests on iOS.
Reverted changeset:
"[ARM64] Use link register instead of pinning a register for
materializing big load constants"
https://bugs.webkit.org/show_bug.cgi?id=228710
https://commits.webkit.org/r280609
2021-08-03 Yijia Huang <yijia_huang@apple.com>
[ARM64] Use link register instead of pinning a register for materializing big load constants
https://bugs.webkit.org/show_bug.cgi?id=228710
Reviewed by Mark Lam.
Previously, we pin a register as a temp for materializing a large constant that cannot fit in
Load/Store imm form. This is not efficient since the register allocator has one less register
to allocate from. To solve this problem, we should switch to using the link register as the temp
on ARM64.
* b3/B3Common.cpp:
(JSC::B3::linkRegister):
(JSC::B3::pinnedExtendedOffsetAddrRegister): Deleted.
* b3/B3Common.h:
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
(JSC::B3::Air::callFrameAddr):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
* b3/air/AirLowerStackArgs.cpp:
(JSC::B3::Air::lowerStackArgs):
2021-08-02 Yijia Huang <yijia_huang@apple.com>
Add a new pattern to instruction selector to utilize UMULL supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=228721
Reviewed by Saam Barati.
Unsigned Multiply Long (UMULL) multiplies two 32-bit register values, and writes the
result to the destination register. This instruction is an alias of the UMADDL instruction.
umull xd wn wm
The equivalent pattern is: d = ZExt32(n) * ZExt32(m)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = Trunc(@0)
Int @2 = ArgumentReg(%x1)
Int @3 = Trunc(@2)
Int @4 = ZExt32(@1)
Int @5 = ZExt32(@3)
Int @6 = Mul(@4, @5)
Void@7 = Return(@6, Terminal)
// Old optimized AIR
Move %x0, %x0, @4
Move %x1, %x1, @5
Mul %x0, %x1, %x0, @6
Ret %x0, @7
// New optimized AIR
MultiplyZeroExtend %x0, %x1, %x0, @6
Ret %x0, @7
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::multiplyZeroExtend32):
* assembler/testmasm.cpp:
(JSC::testMultiplyZeroExtend32):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testMulArgs32SignExtend):
(testMulArgs32ZeroExtend):
* b3/testb3_3.cpp:
(addArgTests):
2021-08-02 Yijia Huang <yijia_huang@apple.com>
Add new patterns to instruction selector to utilize AND/EOR/ORR-with-shift supported by ARM64
https://bugs.webkit.org/show_bug.cgi?id=228675
Reviewed by Saam Barati.
Bitwise AND (shifted register) performs a bitwise AND of a register value and an optionally-shifted
register value, and writes the result to the destination register.
and wd wn wm ShiftType #amount
The equivalent pattern is: n & (m ShiftType amount)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = Const32(63)
Int @3 = Shl(@1, $63(@2))
Int @4 = BitAnd(@0, @3)
Void@5 = Return(@4, Terminal)
// Old optimized AIR
Lshift %x1, $63, %x1, @3
And %x0, %x1, %x0, @4
Ret %x0, @5
// New optimized AIR
AndLeftShift %x0, %x1, $63, %x0, @4
Ret %x0, @5
Bitwise Exclusive OR (shifted register) performs a bitwise Exclusive OR of a register value and an
optionally-shifted register value, and writes the result to the destination register.
eor wd wn wm ShiftType #amount
The equivalent pattern is: n ^ (m ShiftType amount)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = Const32(63)
Int @3 = Shl(@1, $63(@2))
Int @4 = BitXor(@0, @3)
Void@5 = Return(@4, Terminal)
// Old optimized AIR
Lshift %x1, $63, %x1, @3
Xor %x0, %x1, %x0, @4
Ret %x0, @5
// New optimized AIR
XorLeftShift %x0, %x1, $63, %x0, @4
Ret %x0, @5
Bitwise OR (shifted register) performs a bitwise (inclusive) OR of a register value and an
optionally-shifted register value, and writes the result to the destination register.
orr wd wn wm ShiftType #amount
The equivalent pattern is: n | (m ShiftType amount)
Given B3 IR:
Int @0 = ArgumentReg(%x0)
Int @1 = ArgumentReg(%x1)
Int @2 = Const32(63)
Int @3 = Shl(@1, $63(@2))
Int @4 = BitOr(@0, @3)
Void@5 = Return(@4, Terminal)
// Old optimized AIR
Lshift %x1, $63, %x1, @3
Or %x0, %x1, %x0, @4
Ret %x0, @5
// New optimized AIR
OrLeftShift %x0, %x1, $63, %x0, @4
Ret %x0, @5
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::andLeftShift32):
(JSC::MacroAssemblerARM64::andRightShift32):
(JSC::MacroAssemblerARM64::andUnsignedRightShift32):
(JSC::MacroAssemblerARM64::andLeftShift64):
(JSC::MacroAssemblerARM64::andRightShift64):
(JSC::MacroAssemblerARM64::andUnsignedRightShift64):
(JSC::MacroAssemblerARM64::xorLeftShift32):
(JSC::MacroAssemblerARM64::xorRightShift32):
(JSC::MacroAssemblerARM64::xorUnsignedRightShift32):
(JSC::MacroAssemblerARM64::xorLeftShift64):
(JSC::MacroAssemblerARM64::xorRightShift64):
(JSC::MacroAssemblerARM64::xorUnsignedRightShift64):
(JSC::MacroAssemblerARM64::orLeftShift32):
(JSC::MacroAssemblerARM64::orRightShift32):
(JSC::MacroAssemblerARM64::orUnsignedRightShift32):
(JSC::MacroAssemblerARM64::orLeftShift64):
(JSC::MacroAssemblerARM64::orRightShift64):
(JSC::MacroAssemblerARM64::orUnsignedRightShift64):
* assembler/testmasm.cpp:
(JSC::testAndLeftShift32):
(JSC::testAndRightShift32):
(JSC::testAndUnsignedRightShift32):
(JSC::testAndLeftShift64):
(JSC::testAndRightShift64):
(JSC::testAndUnsignedRightShift64):
(JSC::testXorLeftShift32):
(JSC::testXorRightShift32):
(JSC::testXorUnsignedRightShift32):
(JSC::testXorLeftShift64):
(JSC::testXorRightShift64):
(JSC::testXorUnsignedRightShift64):
(JSC::testOrLeftShift32):
(JSC::testOrRightShift32):
(JSC::testOrUnsignedRightShift32):
(JSC::testOrLeftShift64):
(JSC::testOrRightShift64):
(JSC::testOrUnsignedRightShift64):
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/testb3.h:
* b3/testb3_2.cpp:
(testAndLeftShift32):
(testAndRightShift32):
(testAndUnsignedRightShift32):
(testAndLeftShift64):
(testAndRightShift64):
(testAndUnsignedRightShift64):
(testXorLeftShift32):
(testXorRightShift32):
(testXorUnsignedRightShift32):
(testXorLeftShift64):
(testXorRightShift64):
(testXorUnsignedRightShift64):
(testOrLeftShift32):
(testOrRightShift32):
(testOrUnsignedRightShift32):
(testOrLeftShift64):
(testOrRightShift64):
(testOrUnsignedRightShift64):
(addBitTests):
2021-08-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use loadPair / storePair in YarrJIT
https://bugs.webkit.org/show_bug.cgi?id=228687
Reviewed by Mark Lam.
Use loadPair / storePair if possible in YarrJIT. Currently, we are not
deploying Spooler in YarrJIT, but we should do that in the future too.
In this patch, we also add appropriate fallback code in loadPair / storePair:
the offset of these functions are small enough so that we should consider
overflowing case. If it overflows, we use two loads or stores.
This patch also adds loadPair32 and storePair32 to all macro assembler so that
we can call it without CPU(ARM64). Internally, two loads or stores are combined.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::loadPair32):
(JSC::MacroAssemblerARM64::loadPair64):
(JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess):
(JSC::MacroAssemblerARM64::storePair32):
(JSC::MacroAssemblerARM64::storePair64):
(JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::loadPair32):
(JSC::MacroAssemblerARMv7::storePair32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::loadPair32):
(JSC::MacroAssemblerMIPS::storePair32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::loadPair32):
(JSC::MacroAssemblerX86Common::storePair32):
* assembler/testmasm.cpp:
(JSC::testLoadStorePair32):
(JSC::testLoadStorePair64Int64):
* yarr/YarrJIT.cpp:
2021-08-02 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix accidental narrowing
https://bugs.webkit.org/show_bug.cgi?id=228613
Note that this narrowing does not matter semantically since we mask this value with 0x7f.
* yarr/YarrJIT.h:
(JSC::Yarr::BoyerMooreBitmap::addCharacters):
2021-08-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Yarr BoyerMoore search should support character-class
https://bugs.webkit.org/show_bug.cgi?id=228613
Reviewed by Saam Barati.
This patch adds character-class support for BoyerMoore lookahead search in Yarr.
Currently, we only support fixed-sized character-class. We can extend it for repeat cases in the future.
To apply this character-class thing to jQuery's RegExp, we also allow non-fixed-sized disjunction.
For example, /aaaa.*|bbbb/'s disjunction is not fixed-sized. But still we can use (aaaa|bbbb) prefix since
this part is fixed-sized and we know minimum-size of this disjunction is 4.
Plus, instead of giving up BoyerMoore search when we found non-supported terms, we shorten BoyerMoore search
length not to include this term so that we can still have a chance to leverage BoyerMoore search. In the case
of /aaaa|bbbb|ccc(d|e|f)/, we previously gave up since it finds `(d|e|f)`. But now, instead we shorten the length
from 4 to 3, and construct search pattern with `aaa|bbb|ccc`.
This patch improves jquery-todomvc-regexp by 20%.
ToT Patched
jquery-todomvc-regexp 545.3561+-0.6968 ^ 451.6117+-0.4613 ^ definitely 1.2076x faster
This improves Speedometer2/jQuery-TodoMVC by 2%.
----------------------------------------------------------------------------------------------------------------------------------
| subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) |
----------------------------------------------------------------------------------------------------------------------------------
| Elm-TodoMVC |123.470833 |123.550000 |1.000641 | 0.841600 |
| VueJS-TodoMVC |26.883333 |26.950000 |1.002480 | 0.846732 |
| EmberJS-TodoMVC |127.708333 |127.754167 |1.000359 | 0.934206 |
| BackboneJS-TodoMVC |50.545833 |50.445833 |0.998022 | 0.679610 |
| Preact-TodoMVC |20.879167 |20.791667 |0.995809 | 0.796541 |
| AngularJS-TodoMVC |137.479167 |137.275000 |0.998515 | 0.729817 |
| Vanilla-ES2015-TodoMVC |69.079167 |68.912500 |0.997587 | 0.524325 |
| Inferno-TodoMVC |65.604167 |66.120833 |1.007876 | 0.145549 |
| Flight-TodoMVC |77.029167 |76.708333 |0.995835 | 0.518562 |
| Angular2-TypeScript-TodoMVC |40.516667 |40.812500 |1.007302 | 0.513386 |
| VanillaJS-TodoMVC |54.762500 |54.895833 |1.002435 | 0.647381 |
| jQuery-TodoMVC |255.950000 |250.425000 |0.978414 | 0.000000 (significant) |
| EmberJS-Debug-TodoMVC |341.745833 |342.804167 |1.003097 | 0.219937 |
| React-TodoMVC |88.854167 |88.700000 |0.998265 | 0.568405 |
| React-Redux-TodoMVC |151.266667 |150.804167 |0.996942 | 0.256403 |
| Vanilla-ES2015-Babel-Webpack-TodoMVC |65.783333 |65.645833 |0.997910 | 0.437464 |
----------------------------------------------------------------------------------------------------------------------------------
a mean = 246.52898
b mean = 246.85128
pValue = 0.3927330278
(Bigger means are better.)
1.001 times better
Results ARE NOT significant
* yarr/YarrJIT.cpp:
(JSC::Yarr::BoyerMooreInfo::shortenLength):
(JSC::Yarr::BoyerMooreInfo::setAll):
(JSC::Yarr::BoyerMooreInfo::addCharacters):
(JSC::Yarr::BoyerMooreInfo::addRanges):
* yarr/YarrJIT.h:
(JSC::Yarr::BoyerMooreBitmap::add):
(JSC::Yarr::BoyerMooreBitmap::addCharacters):
(JSC::Yarr::BoyerMooreBitmap::addRanges):
(JSC::Yarr::BoyerMooreBitmap::setAll):
(JSC::Yarr::BoyerMooreBitmap::isAllSet const):
2021-08-02 Stephan Szabo <stephan.szabo@sony.com>
[PlayStation] Make C files in testapi compile with a C standard rather than C++ one
https://bugs.webkit.org/show_bug.cgi?id=228701
Reviewed by Ross Kirsling.
* shell/PlatformPlayStation.cmake: Set standard for C files in testapi
2021-08-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Yarr should use Bitmap instead of ByteVector for BoyerMoore search
https://bugs.webkit.org/show_bug.cgi?id=228676
Reviewed by Saam Barati.
We observed that using Bitmap instead of ByteVector does not pose performance
issue. It was neutral in jquery-todomvc-regexp.js. In that case, we should use
Bitmap since it is 8x smaller.
We also search reusable Bitmap from Vector since comparing 128bit Bitmap is
super fast so we do not need to bother about linear search here (# of Bitmap
is currently up to 4).
To make code simplified, we add regT2 to ARMv7 and MIPS backend of YarrJIT.
ToT Patched
jquery-todomvc-regexp 555.9566+-0.8856 555.0737+-0.9717
* yarr/YarrJIT.cpp:
(JSC::Yarr::BoyerMooreInfo::index const): Deleted.
(JSC::Yarr::BoyerMooreInfo::setIndex): Deleted.
* yarr/YarrJIT.h:
(JSC::Yarr::YarrCodeBlock::set8BitCode):
(JSC::Yarr::YarrCodeBlock::set16BitCode):
(JSC::Yarr::YarrCodeBlock::set8BitCodeMatchOnly):
(JSC::Yarr::YarrCodeBlock::set16BitCodeMatchOnly):
(JSC::Yarr::YarrCodeBlock::tryReuseBoyerMooreBitmap const):
(JSC::Yarr::BoyerMooreByteVector::BoyerMooreByteVector): Deleted.
(JSC::Yarr::YarrCodeBlock::tryReuseBoyerMooreByteVector const): Deleted.
2021-07-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Move JIT_UNICODE_EXPRESSIONS to ENABLE(YARR_JIT_UNICODE_EXPRESSIONS) in PlatformEnable.h
https://bugs.webkit.org/show_bug.cgi?id=228669
Reviewed by Alexey Shvayka.
Move JIT_UNICODE_EXPRESSIONS to PlatformEnable.h to align to the other YarrJIT flags.
This makes it easy to read that this is enabled on ARM64 and X86_64.
* yarr/YarrJIT.cpp:
2021-07-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Clean up Yarr by using `static constexpr`
https://bugs.webkit.org/show_bug.cgi?id=228678
Reviewed by Alexey Shvayka.
Modernize Yarr code by using static constexpr.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::TrustedImm32::TrustedImm32):
* yarr/YarrCanonicalizeUCS2.cpp:
* yarr/YarrCanonicalizeUCS2.js:
(set characters.hex.set string_appeared_here):
* yarr/YarrErrorCode.cpp:
(JSC::Yarr::errorMessage):
* yarr/YarrJIT.cpp:
2021-07-31 Joonghun Park <jh718.park@samsung.com>
Unreviewed. Remove the build warning below since r280493.
warning: variable ‘block’ set but not used [-Wunused-but-set-variable]
* b3/B3CanonicalizePrePostIncrements.cpp:
(JSC::B3::canonicalizePrePostIncrements):
2021-07-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] branchTest8 should not emit tst for Zero/NonZero cases
https://bugs.webkit.org/show_bug.cgi?id=228674
Reviewed by Mark Lam.
Previously, branchTest8(NonZero, BaseIndex) emits `tst` instruction
unnecessarily. This is because the mask is truncated into 8bit, which
makes branchTest32 (which is internally used in branchTest8) emits tst.
We observed many unnecessary tst in YarrJIT.
This patch removes this unnecessary truncation since Zero/NonZero does
not care high bits of mask in branchTest8. This is ok because the
ResultCondition version of mask8OnCondition() is always used to generate
a mask that is only used against a value that is loaded with
MacroAssemblerHelpers::load8OnCondition(). For Zero/NonZero conditions,
load8OnCondition() will always zero fill the upper bytes. The 0 filled
upper bytes will not affect the result of a branch on zero or branch on
not zero.
Before:
0x10a8068b0: ldrb w16, [x7, x6]
0x10a8068b4: tst w16, #0xff
0x10a8068b8: b.ne 0x10a8068cc
After:
0x1070068b0: ldrb w16, [x7, x6]
0x1070068b4: cbnz w16, 0x1070068c8
* assembler/MacroAssemblerHelpers.h:
(JSC::MacroAssemblerHelpers::mask8OnCondition):
2021-07-30 Robin Morisset <rmorisset@apple.com>
Improve OSR entry into Wasm loops with arguments
https://bugs.webkit.org/show_bug.cgi?id=228595
Reviewed by Yusuke Suzuki.
This patch has two parts:
- improve the Wasm OSR code to fully support loop arguments (just some plumbing to make sure that the right values are propagated)
- improve the B3 validator to fix a hole I noticed while writing the first part: we were not detecting code that introduce Upsilons in the wrong blocks.
Naturally, this caused hard to debug issues, as B3 has no well-defined semantics for a Phi that is reached before the corresponding Upsilon(s).
* b3/B3Validate.cpp:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
(JSC::Wasm::AirIRGenerator::addLoop):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
(JSC::Wasm::B3IRGenerator::addLoop):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addLoop):
2021-07-30 Philip Chimento <pchimento@igalia.com>
[JSC] Rename Temporal.now to Temporal.Now
https://bugs.webkit.org/show_bug.cgi?id=228658
Reviewed by Yusuke Suzuki.
See https://github.com/tc39/proposal-temporal/pull/1645. In the July
2021 meeting TC39 achieved consensus to rename Temporal.now to
Temporal.Now since it is a namespace.
* runtime/TemporalNow.cpp: Change Now[@@toStringTag] accordingly.
* runtime/TemporalObject.cpp: Rename now property to Now.
2021-07-30 Tadeu Zagallo <tzagallo@apple.com>
putInlineFastReplacingStaticPropertyIfNeeded should handle custom values
https://bugs.webkit.org/show_bug.cgi?id=227963
Reviewed by Alexey Shvayka.
Follow up after r280463: as it turns out, putInlineFastReplacingStaticPropertyIfNeeded also needs to handle
custom values, similar to how definePropertyOnReceiverSlow was updated. This function will be called when the
target property of the receiver is a custom value and isn't reified. The previous test case was expanded to
test both the reified and non-reified cases.
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded):
* tools/JSDollarVM.cpp:
2021-07-30 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix wrong access width
https://bugs.webkit.org/show_bug.cgi?id=228301
rdar://81341472
* yarr/YarrJIT.cpp:
2021-07-30 Yijia Huang <yijia_huang@apple.com>
Add Pre/Post-Indexed Address Mode to Air for ARM64
https://bugs.webkit.org/show_bug.cgi?id=228047
Reviewed by Phil Pizlo.
Pre-indexed addressing means that the address is the sum of the value in the 64-bit base register
and an offset, and the address is then written back to the base register. And post-indexed
addressing means that the address is the value in the 64-bit base register, and the sum of the
address and the offset is then written back to the base register. They are relatively common for
loops to iterate over an array by increasing/decreasing a pointer into the array at each iteration.
With such an addressing mode, the instruction selector can merge the increment and access the array.
#####################################
## Pre-Index Address Mode For Load ##
#####################################
LDR Wt, [Xn, #imm]!
In B3 Reduction Strength, since we have this reduction rule:
Turn this: Load(Add(address, offset1), offset = offset2)
Into this: Load(address, offset = offset1 + offset2)