Skip to content

V
V8
Switch branch/tag
  1. 16 Oct, 2019 37 commits
  3. 15 Oct, 2019 3 commits
    • Deepti Gandluri's avatar
      [wasm-simd] Add AVX codegen for most I32x4 SIMD ops · 9a9fc1c1
      Deepti Gandluri authored 
      Bug: v8:9854
Change-Id: Icb41622caa4a7e0a7262048f69b40cfbe8fa17bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860406Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64302}
      9a9fc1c1
    • Milad Farazmand's avatar
      PPC/s390: [Liftoff] Improve initialization for many locals · c314cf74
      Milad Farazmand authored 
      Port a8cdda99

Original Commit Message:

    WebAssembly locals are specified to be zero on function entry. Liftoff
    implements this by just storing the constant 0 in the virtual stack for
    integer types, and using one floating point register initialized to
    zero for all floating point types.
    For big counts of locals this leads to problems (manifesting as huge
    blocks of code being generated) once we hit a merge point: All those
    constants (for int) and all duplicate register uses (for floats) need to
    be fixed up, by using separate registers for the locals or spilling to
    the stack if no more registers are available. All this spilling
    generates a lot of code, and can even happen multiple times within a
    function.

    This CL optimizes for such cases by spilling all locals to the stack
    initially. All merges within the function body get much smaller then.
    The spilled values rarely have to be loaded anyway, because the initial
    zero value is usually overwritten before the first use.

    To optimize the code size for initializing big numbers of locals on the
    stack, this CL also introduces the platform-specific
    {FillStackSlotsWithZero} method which uses a loop for bigger local
    counts.

    This often saves dozens of kilobytes for very big functions, and shows
    an overall code size reduction of 4-5 percent for big modules.

R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I2459080a1f6acfdd212e9a93a868d028980c5554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863370Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#64301}
      c314cf74
    • Adam Klein's avatar
      Add verwaest as an API owner · e359c49b
      Adam Klein authored 
      Previous API owners (adamk, yangguo) are less-involved with the JS API
then ever, so it seems appropriate to have an owner whose responsibility
is squarely in the JS domain.

Change-Id: I4235778fda8f55d0429e875d52ff74049024dad1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860328Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64300}
      e359c49b