1. 12 Apr, 2017 6 commits
    • 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
  2. 11 Apr, 2017 34 commits