- 02 Jun, 2020 4 commits
-
-
Seth Brenith authored
This change adds more granular control to the behavior that was previously controlled by the single flag --turbo-profiling. With this change, it becomes possible to: - output information only about builtins, ignoring functions compiled at runtime - skip the very slow process of writing the schedule and disassembly for all builtins, if you only want the block counts and don't need verbose output This change also moves the output step from Shell::OnExit to Isolate::DumpAndResetStats so that it's more consistent with other features and works in hosts other than d8. Bug: v8:10470, v8:9119 Change-Id: I19b1caca3ff27a2e4a6fdc7ad2f8174f8d678b3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216717Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68104}
-
George Wort authored
Display UsePositions in the intervals in live ranges in turbolizer. Uses are shown as vertical red lines. Bug: v8:7327 Change-Id: Iab8d08989b9113d1b7d393252de5988e8b25b8de Notry: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2224215 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68102}
-
Jakob Gruber authored
If --turbo-nci is enabled, use compare op builtins with feedback collection during generic lowering. Bug: v8:8888 Change-Id: I886020e2ee280f65388d9987c70958546f99e0f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215821Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68100}
-
Georg Neis authored
Bug: chromium:1085804 Change-Id: I98f12da97334bd5fd32bd01b1eca56be895dc0a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218286 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#68095}
-
- 29 May, 2020 2 commits
-
-
Milad Farazmand authored
Change-Id: I33412dcf08106d717d11ee37d29b2a3c1d608727 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219280Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#68078}
-
Milad Farazmand authored
Change-Id: Ied5f36130aae65631ccb05c3bbef4ca9ab88fbc8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219275Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#68073}
-
- 28 May, 2020 3 commits
-
-
Ng Zhi An authored
Implements f32x4 ceil, floor, trunc, nearestint, for interpreter and x64. Bug: v8:10553 Change-Id: Iab747cbd2a872aa6cd4ad23c5b8334d5c8e4da61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212435Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#68054}
-
Nico Hartmann authored
This is a reland of 6204768b The original issue exposed the problem that NumberEqual performs implicit conversion of oddballs to numbers, which is incorrect for abstract equality comparison (i.e. 0 == null must not be true). This reland fixes this by applying the following steps: * Introduced a new kNumberOrBoolean value for CompareOperationFeedback, CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode. * In CodeStubAssembler::Equal: Further distinguish between boolean and non-boolean oddballs and set feedback accoringly. * In JSTypedLowering: Construct [Speculative]NumberEqual operator with CompareOperationHint::kNumberOrBoolean, when this feedback is present. JSOperatorBuilder and operator cache are extended accordingly. * In SimplifiedLowering: Propagate a UseInfo with new TypeCheckKind::kNumberOrBoolean. * This leads to the generation of CheckedTaggedToFloat64 in RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean. * In EffectControlLinearizer: Handle this new mode. Accept and convert number and boolean and deopt for rest. Original change's description: > [turbofan] Improve equality on NumberOrOddball > > This CL cleans up CompareOperationFeedback by replacing it with a > composable set of flags. The interpreter is changed to collect > more specific feedback for abstract equality, especially if oddballs > are involved. > > TurboFan is changed to construct SpeculativeNumberEqual operator > instead of the generic JSEqual in many more cases. This change has > shown a local speedup of a factor of 3-10, because the specific > operator is way faster than calling into the generic builtin, but > it also enables additional optimizations, further improving > runtime performance. > > Bug: v8:5660 > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854 > Reviewed-by: Mythri Alle <mythria@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67645} TBR: tebbi@chromium.org Bug: v8:5660 Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68037}
-
Marja Hölttä authored
See https://github.com/tc39/proposal-promise-any/pull/64/ Bug: v8:9808 Change-Id: I5f11a5e306d17372ba7c24f313165de985444470 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214826 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#68034}
-
- 27 May, 2020 7 commits
-
-
Ng Zhi An authored
all_true uses pcmpeqd which takes a memory operand, but needs to be 128-bit aligned, which we don't support yet. Bug: v8:9198 Change-Id: Ia0caaaa76b1103ba538252181ef93e8557fb4739 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218887Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#68027}
-
Milad Farazmand authored
Port 043ac205 Original Commit Message: Implement i8x16.bitmask, i16x8.bitmask, i32x4.bitmask on x64. R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I1bb6439abb3db27c50e1f06a833954c473119bcd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219007Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#68023}
-
George Wort authored
Display register allocation live ranges alongside sequences in turbolizer. The existing --trace-turbo flag now also outputs the register allocation data as part of the json file alongside the instruction sequence data that is already produced before and after register allocation is performed. This data includes live range intervals for each virtual and fixed register and the state of their assignments. This json data can now be displayed in turbolizer alongside the instruction sequences. The information is presented as a grid, with each grid cell representing a LifeTimePosition of a certain virtual register, determined by the column and row indices respectively. Each LifeTimePosition is shown to be part of an instruction id which itself is shown to be part of a block id. Each interval is shown as a coloured rectangle positioned over the relevant cells, and displaying text to indicate the state of their assignment. The Resizer object has been extended to allow the grid's html panel to be varied in size in the same manner that the left and right panels can be. The size of the grid itself must also be adjusted whenever the div container changes size. The RangeView class is introduced and is created and held by the single SequenceView object used to display the InstructionSequence data before and after register allocation. A checkbox allows the user to show/hide the range view, this is disabled when register allocation data is not provided or more than 249 instructions are in the sequence. The latter being required due to the css grid-row-col limit of 1000 alond with helping alleviate performance issues. The SequenceView object tracks the phase index currently selected as well as whether or not it is currently being shown. This ensures that the RangeView is not hidden and shown when switching between before and after register allocation, allowing for a smoother transition between the two. The scroll position is also saved and restored for convenience. The data about the instruction sequence required for the display is held by the RangeView object and reset whenever a new instruction sequence is shown. The grid div must sync its scroll with the headers and row labels so as to ensure a consistent view. The register allocation data is extracted from the json, with each register row showing all intervals within the relevant ranges. When the view is switched between before and after register allocation, the relevant intervals are swapped in. Bug: v8:7327 Notry: true Change-Id: I183535a2410a7d663382f387199885250fb98691 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184232Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68019}
-
Santiago Aboy Solanes authored
Since now all phases have the same order (or the reverse) we can share only one container that would specify the traversal order. We still need a queue that will be used for revisiting purposes in PROPAGATE and RETYPE. Bug: v8:10424 Change-Id: Iab1e3c3cf6ffd342240d43be3b8ac77812aff211 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154201 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68008}
-
Santiago Aboy Solanes authored
We now have one initial phase (before PROPAGATE) that generates the traversal that the subphases are going to take. Generates post-order starting from End for RETYPE and LOWER, and the reverse for PROPAGATE. As a note, LOWER could use either PO or RPO. Bug: v8:10424 Change-Id: I7435d681aba012b4f5e5ecd971bfa1d88bfb8b3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154785Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68007}
-
Jakob Gruber authored
The `slot` parameter is expected to be a UintPtr. Bug: v8:8888 Change-Id: Ia1137cd5af3d3aa0b00e9bf194661067c37332b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215047 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68005}
-
Manos Koukoutos authored
Motivation: In the wasm-gc proposal, structs and arrays are allowed to store elements of packed types i8 and i16. Changes: - Add i8 and i16 to ValueType. - Fix all case switches to handle the new cases. - Add a couple helper methods to ValueType and improve the implementation/usage of a couple more. Bug: v8:7748 Change-Id: I527cfe5acf5d877fc38e4212174ba9f9de5c40ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215046Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#67994}
-
- 26 May, 2020 8 commits
-
-
Ng Zhi An authored
This removes the post-mvp flag for bitmask, since it was accepted into the proposal, see https://github.com/WebAssembly/simd/pull/201. Bug: v8:10308 Change-Id: I4ced43a6484660125d773bc9de46bdea9f72b13b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216532Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67993}
-
Ng Zhi An authored
See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html for more on this warning. Bug: v8:10488 Change-Id: I872782060c22812c93eadf4f77ba75c058283b8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210779 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67987}
-
Ng Zhi An authored
See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html for more on this warning. Bug: v8:10488 Change-Id: I78fdfb904ea94d9ae034b41cd43be8689a0096ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211188 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67985}
-
Seth Brenith authored
VisitWord32EqualImpl was checking for inputs of type kCompressedHeapConstant, but it can also sometimes have inputs of type kHeapConstant. In either case, we can check for whether to do a load from the roots array. This improves Octane score by about 3% (or about 1.5% if --no-opt is specified). Bug: v8:8948 Change-Id: Iab6c0b1dacd96c74e4cfb54c772aa92e5baf00ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213081 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#67981}
-
Milad Farazmand authored
Change-Id: I5a93231b16c8291c87fce57062837dce886bc2f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216231Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67975}
-
Victor Gomes authored
This CL is a step towards reversing JS stack arguments for TurboFan. It does the following: 1. Add StackOrder to CallInterfaceDescriptor 2. Reverse arguments in TF backend for JS calls. 3. Cleanup TFJ builtins interface descriptors, since calls for these builtins already reverse the arguments, we don't need to reverse the interface descriptor anymore. Change-Id: Ie840b1757bf023aa381a7fa01cbe66e7cf90778f Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213440Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#67971}
-
Jakob Gruber authored
... and CallParameters::arity(). The construct arity contains the actual argument count, plus 2 for the target (the first input) and new target (the last input). This CL adds a named constant and a helper method for accessing arity without extra args. In the future we may want to remove the extra args from arity() altogether. Call arity is similar but includes the target and receiver. Bug: v8:10542,v8:8888 Change-Id: I850fa314f88c2bee9d4dcd87eac9295b2bf88281 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208850 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67963}
-
Jakob Gruber authored
If --turbo-nci is enabled, use unary op builtins with feedback collection during generic lowering. Bug: v8:8888 Change-Id: Ie32cfe1558a7fbada2ac69a99ef969097558bc89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209067 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67962}
-
- 25 May, 2020 2 commits
-
-
Daniel Clifford authored
Change-Id: I092c0d70bf517b4c714f5958b188d54030dd9774 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932838 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67954}
-
Ross McIlroy authored
We can't consistently rewire the successor blocks of an unreachable node to disconnect them from the graph when we are trying to maintain the schedule. Instead simply leave the code there. As a future optimization we could add a proper scheduled dead code elimination phase which can deal with this. As a side-effect, one of the tests sees a int64 DeadValue, so add support for that in the instruction selector. BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684 Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67953}
-
- 22 May, 2020 1 commit
-
-
Seth Brenith authored
Sometimes CSA code carefully constructs a mask to check several bitfields at once. Thus far, such a check has been very awkward to write in Torque. This change adds a way to do so, using the non-short-circuiting binary `&` operator. So now you can write an expression that depends on several bitfields from a bitfield struct, like `x.a == 5 & x.b & !x.c & x.d == 2` (assuming b is a one-bit value), and it will be reduced to a single mask and equality check. To demonstrate a usage of this new reduction, this change ports the trivial macro IsSimpleObjectMap to Torque. I manually verified that the generated code for the builtin SetDataProperties, which uses that macro, is unchanged. Bug: v8:7793 Change-Id: I4a23e0005d738a6699ea0f2a63f9fd67b01e7026 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183276 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67948}
-
- 21 May, 2020 3 commits
-
-
Ng Zhi An authored
From 10 to 8 instructions (each). We do this by using mi (instead of lt) and ls (instead of le), which check for strictly less than and greater than or unordered. That way we don't have to have an extra mov for NaN. Change-Id: I18ff876ac12b7097d73d6cbbb64de6c2a1148e43 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208934Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67947}
-
Ng Zhi An authored
The proposal uses the lane shape, e.g. i64x2.anytrue, and we were using s1x2.anytrue in our opcodes. This was a legacy naming, because we were trying to bitpack the booleans. Now that we aren't doing that, rename these to be more consistent with the proposal. This was done with a straightforward sed script, changing both cpp code and also some comments in mjsunit test files. Bug: v8:10506 Change-Id: If077ed805de23520d8580d6b3b1906c80f67b94f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207915 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67945}
-
Seth Brenith authored
Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
-
- 20 May, 2020 1 commit
-
-
Milad Farazmand authored
load_extend is now implanted on BE machines by loading bytes and using replace_lane to add it to the desired lane. Interpret is also fixed to write lanes in reverse. Change-Id: I984ae6b4bd41544fbf65c702a4b5b50ba03cb261 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210147 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#67935}
-
- 19 May, 2020 4 commits
-
-
Ng Zhi An authored
Bug: v8:10501 Change-Id: Ib61f7957e1fd7cfa498bce28171b5f9e4b2f93c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191393 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#67913}
-
Ng Zhi An authored
For load extends, we can use Ldr, which does not require us to manually calculate address - ld1r uses post-index, so we have to add the index ourselves. By checking the operation in the instruction-selector, we can set the addressing mode for load extends to be MRR, then use Ldr in the codegen. Bug: v8:9886 Change-Id: Ibcd22fa719cd6dafd2fd06e68066960db249b57a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207656Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67912}
-
Jakob Gruber authored
Call_WithFeedback CallWithArrayLike_WithFeedback CallWithSpread_WithFeedback ConstructWithArrayLike_WithFeedback ConstructWithSpread_WithFeedback These are used in generic lowering if --turbo-nci is passed. Bug: v8:8888 Change-Id: I78b56a1f358fa7c213e375eeb2feaa65432adfdb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199352Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67888}
-
Ng Zhi An authored
The lowering for anytrue was assuming that the input nodes are all integers. The regression test added in https://crrev.com/c/2194471 calls anytrue with float operands, this was causing the lowering to generate cmpl instructions with a float register and an immediate, which is wrong. The fix is to use GetReplacementsWithType on the input nodes, but only if the input were floats, since we use Word32Equal. Drive-by clean up of comments in the aforementioned regression test. Bug: v8:10535 Change-Id: I4de89516c178e9003a4c745808d831be87918381 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203400 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67878}
-
- 18 May, 2020 5 commits
-
-
Ng Zhi An authored
The codegen uses a bunch of vpmax to try and keep set bits around. The datatype for vpmax does not need to change for each instruction, since vpmax U32 will persist set bits just as well. This simplifies the instruction sequences for S1x8 and S1x16 anytrue. I added a test to check a special case when a f64x2 contains -0.0 (top bit set). A previous attempt to optimize codegen used floating point compare, which does not distinguish between 0.0 and -0.0. So -0.0 will compare equals to 0.0, and incorrect return 0 for anytrue. Change-Id: I66013796af08a666009e6b2d774ea7ee7bdfe1ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203113 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67875}
-
Jakob Gruber authored
This is a reland of 69f42d40 Original change's description: > [nci] Add Construct_WithFeedback builtin > > This builtin essentially acts like InterpreterAssembler::Construct. It > collects full feedback, then tail-calls either the array constructor > or the construct builtin. > > For now, it is only used in generic lowering, if the --turbo-nci flag > is passed. One of the next steps will be to measure performance impact > of feedback collection. If minimal, we may want to enable it > unconditionally in generic lowering. > > Bug: v8:8888 > Change-Id: I8a460a2b5954c26fa72658045a8423c5eee6b611 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198775 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67850} Tbr: neis@chromium.org Bug: v8:8888 Change-Id: Ib1a81da998c848d63c0119b3a4e90fc917b15e94 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2206738 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67864}
-
Jakob Gruber authored
This reverts commit 69f42d40. Reason for revert: The last PS introduced a bug https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20fyi/15897. Original change's description: > [nci] Add Construct_WithFeedback builtin > > This builtin essentially acts like InterpreterAssembler::Construct. It > collects full feedback, then tail-calls either the array constructor > or the construct builtin. > > For now, it is only used in generic lowering, if the --turbo-nci flag > is passed. One of the next steps will be to measure performance impact > of feedback collection. If minimal, we may want to enable it > unconditionally in generic lowering. > > Bug: v8:8888 > Change-Id: I8a460a2b5954c26fa72658045a8423c5eee6b611 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198775 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67850} TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org Change-Id: I3af168373978d773385b9eda9bc1e243e3cbea09 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8888 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2206737Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67860}
-
Clemens Backes authored
We constantly fight against scrambled output with --print-wasm-code and other flags. Passing --single-threaded only partially mitigates this, because there could still be multiple isolates (e.g. Workers), and we sometimes failed to really execute in a single thread if that flag was set. Hence this CL solves the problem in a more fundamental way: Whenever a {StdoutStream} is constructed, it implicitly takes a global recursive mutex. The recursive mutex is needed because we still have some printing methods that don't take a stream as parameter, and instead create their own instance of {StdoutStream}, which should not crash of course. The overhead of taking a mutex should be acceptable, since output to stdout mostly happens if special tracing flags have been passed, and is slow anyway. This CL ensures that the {StdoutStream} is used at least for --print-code, --print-wasm-code, and --trace-turbo-graph. More flags can later be ported on demand. The {JSHeapBroker} class was modified to not contain a {StdoutStream}, but instead create one on demand. R=mlippautz@chromium.org, tebbi@chromium.org CC=ahaas@chromium.org Bug: v8:10506 Change-Id: Ib9cf8d76aa79553b4215bb7775e6d47a8179aafa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201767Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67855}
-
Jakob Gruber authored
This builtin essentially acts like InterpreterAssembler::Construct. It collects full feedback, then tail-calls either the array constructor or the construct builtin. For now, it is only used in generic lowering, if the --turbo-nci flag is passed. One of the next steps will be to measure performance impact of feedback collection. If minimal, we may want to enable it unconditionally in generic lowering. Bug: v8:8888 Change-Id: I8a460a2b5954c26fa72658045a8423c5eee6b611 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198775 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67850}
-