Skip to content

V
V8
Switch branch/tag
  1. 26 May, 2020 21 commits
  3. 25 May, 2020 11 commits
  5. 22 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Generate better code when using `&` operator on bitfields · 98438d86
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67948}
      98438d86
  7. 21 May, 2020 7 commits
    • Ng Zhi An's avatar
      [wasm-simd][arm] Improve f64x2 lt and le codegen · d48bbd52
      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: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67947}
      d48bbd52
    • Ng Zhi An's avatar
      [wasm-simd] Fix pmin pmax opcodes · b409a441
      Ng Zhi An authored 
      These were changed in the renumbering
https://github.com/WebAssembly/simd/blob/master/proposals/simd/NewOpcodes.md

Bug: v8:10501
Change-Id: I4e98b0a482e18208b63f11a1675a90c9367a6d93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212682Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67946}
      b409a441
    • Ng Zhi An's avatar
      [wasm-simd] Rename anytrue and alltrue to follow proposal · 4c2f84b5
      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: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67945}
      4c2f84b5
    • Seth Brenith's avatar
      [diagnostics] Support --turbo-profiling for builtins · 18c73676
      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: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67944}
      18c73676
    • Santiago Aboy Solanes's avatar
      [csa][cleanup] Template TaggedToParameter · 16a23e9a
      Santiago Aboy Solanes authored 
      Some non-templated uses remain until further TNodification.

Bug: v8:9708, v8:6949
Change-Id: Ica841f95a6ddfbdea78589f9db47c5b4126497f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212263
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67943}
      16a23e9a
    • Santiago Aboy Solanes's avatar
      [csa][cleanup] TNodify/remove ParameterMode PossiblyGrowElementsCapacity · 1443d07b
      Santiago Aboy Solanes authored 
      Bug: v8:9708, v8:6949
Change-Id: Ia57ba7e0e24f5f402147246981ba1a1c30295abf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212262Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67942}
      1443d07b
    • Santiago Aboy Solanes's avatar
      [csa][cleanup] Remove unused functions · 46ae85d9
      Santiago Aboy Solanes authored 
      Bug: v8:9708, v8:6949
Change-Id: I60237b03a474a9d8e30bf48b6d9196a07fb81171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212261Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67941}
      46ae85d9