Skip to content

V
V8
Switch branch/tag
  1. 12 Apr, 2017 9 commits
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Refactor and extend InterpretedFrame · 8a6718b1
      Clemens Hammacher authored 
      Similar to WasmInterpreter::Thread, we now also use the pimpl idiom for
InterpretedFrame, hiding the implementation completely in the .cc file.
This allows us to store just two things per InterpretedFrameImpl: The
corresponding thread, and the frame index.
The external interface changes to always return a std::unique_ptr,
because the object layout is not known via the public interface, hence
objects cannot be stack allocated. They also cannot be copied or passed
by value.

The frame inspection interface will be tested after another fix in
https://chromium-review.googlesource.com/474749.

R=ahaas@chromium.org
BUG=v8:5822

Change-Id: I7b109da73df745fac97ec72cb0cf4f0ad71e5da9
Reviewed-on: https://chromium-review.googlesource.com/472887Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44600}
      8a6718b1
    • jgruber's avatar
      [regexp] Consider surrogate pairs when optimizing disjunctions · 46355724
      jgruber authored 
      RationalizeConsecutiveAtoms optimizes ab|ac|az to a(?:b|c|d).
Ensure that this optimization does not split surrogate pairs in unicode
mode.

BUG=chromium:641091

Review-Url: https://codereview.chromium.org/2813893002
Cr-Commit-Position: refs/heads/master@{#44599}
      46355724
    • bmeurer's avatar
      [turbofan] Fix typing rule for CheckBounds. · 483812d4
      bmeurer authored 
      As of crrev.com/2760213003, the CheckBounds operator passes a truncation
that identfies zero and minus zero. However that was not reflected in
the typing rule, and as such the type of CheckBounds(-0,length) was
always Type::None. That confused the typed alias analysis in the
LoadElimination and led to ignoring StoreElement nodes.

BUG=chromium:708050
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2812013006
Cr-Commit-Position: refs/heads/master@{#44598}
      483812d4
    • dusan.simicic's avatar
      MIPS[64]: Support for some SIMD operations (4) · 8d2db536
      dusan.simicic authored 
      Add support for F32x4Abs, F32x4Neg, F32x4RecipApprox,
F32x4RecipRefine, F32x4RecipSqrtApprox, F32x4RecipSqrtRefine,
F32x4Add, F32x4Sub, F32x4Mul, F32x4Max, F32x4Min,
F32x4Eq, F32x4Ne, F32x4Lt, F32x4Le, I32x4SConvertF32x4,
I32x4UConvertF32x4 operations for mips32 and mips64
architectures.

BUG=

Review-Url: https://codereview.chromium.org/2778203002
Cr-Commit-Position: refs/heads/master@{#44597}
      8d2db536
    • Camillo Bruni's avatar
      [elements] Dehandlify ElementsAccessor::HasElement as it cannot allocate · a615efaa
      Camillo Bruni authored 
      Change-Id: I8a20bff1f029df74732899db0b8a9ddc1f4f26d6
Reviewed-on: https://chromium-review.googlesource.com/474827Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44596}
      a615efaa
    • bmeurer's avatar
      [turbofan] Use unreliable LOAD_IC feedback for Array.prototype.push. · 1fceaf9f
      bmeurer authored 
      Add the notion of reliable vs. unreliable receiver map information to
the NodeProperties::InferReceiverMaps machinery. The information is
considered reliable here if the maps are known to be valid based on the
effect chain, and unreliable if there was a side-effect in between that
might have changed the receiver map.

Use this unreliable information for Array.prototype.push, guarded by
either stability dependencies or map checks, which might present a
potential deoptimization loop, which is very unlikely, but still needs
fixing in the future. This is important to optimize calls to push even
in cases like this

  array.push(something.func());

where we have a side-effect (the call to something.func) between the
load of array.push and the actual call.

R=jarin@chromium.org
BUG=v8:5267,v8:6241

Review-Url: https://codereview.chromium.org/2812233002
Cr-Commit-Position: refs/heads/master@{#44595}
      1fceaf9f
    • Sathya Gunasekaran's avatar
      [builtins] Change semantics of class constructors returning primitives · a7c4e778
      Sathya Gunasekaran authored 
      This change mirrors the semantics for derived class constructors. This
change doesn't affect non class constructors.

This change could potentially break web compat. More details:
https://github.com/tc39/ecma262/pull/469

Bug=v8:5536

Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495
Reviewed-on: https://chromium-review.googlesource.com/461225Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44594}
      a7c4e778
    • bmeurer's avatar
      Revert "[turbofan] Avoid going through ArgumentsAdaptorTrampoline for CSA/C++ builtins." · d98dfd8b
      bmeurer authored 
      This reverts commit 9df5674b because it
is not compatible with the way that Array.prototype.reduceRight and
Array.prototype.reduce deal with optional parameters at this point (i.e.
parameters where the behavior is different depending on whether the
parameter was skipped or undefined was passed).

In general, it might be better to not adapt arguments for builtins with
optional paramters, that are likely skipped, for example as in
Object.create or Array.prototype.reduce. Since that will require
arguments adaptor frames for normal calls, especially from baseline
code. Instead it might make sense to use the variadic arguments support
in the CodeStubAssembler instead to avoid the arguments adaptor in all
cases (not only when called from TurboFan optimized code).

BUG=v8:5267,chromium:709782,chromium:707992,chromium:708282,chromium:708599,chromium:709173,chromium:709747,chromium:707065,chromium:710417
TBR=danno@chromium.org

Review-Url: https://codereview.chromium.org/2817653002
Cr-Commit-Position: refs/heads/master@{#44593}
      d98dfd8b
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 7829af32
      mtrofin authored 
      Today, the semantics of:

WebAssembly.instantiate

and

WebAssembly.compile().then(new WebAssemblyInstance)

are subtly different, to the point where attempting the proposed
change uncovered bugs.

In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.

This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.

- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.

BUG=chromium:697028

Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44592}
      7829af32
  3. 11 Apr, 2017 31 commits