1. 12 Apr, 2017 17 commits
    • bmeurer's avatar
      [turbofan] Remove unused word32 truncation case for CheckFloat64Hole. · 2eeb0854
      bmeurer authored
      BUG=chromium:684208,chromium:709753,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2811153003
      Cr-Commit-Position: refs/heads/master@{#44608}
      2eeb0854
    • yangguo's avatar
      [debug,api] Do not use embedder field for debug context id. · 5f90a6eb
      yangguo authored
      We used to reserve the 0-th embedder data field for the debug
      context id. This is no longer necessary since the inspector
      has migrated to be part of V8. This makes the API a bit simpler.
      
      R=clemensh@chromium.org, jochen@chromium.org, kozyatinskiy@chromium.org
      BUG=v8:5530
      
      Review-Url: https://codereview.chromium.org/2806303002
      Cr-Commit-Position: refs/heads/master@{#44607}
      5f90a6eb
    • jgruber's avatar
      [string] Add a fast path to String.p.replace · f4ba786d
      jgruber authored
      This adds a fast path to skip runtime calls to GetSubstitution when
      the replacer string does not contain a '$' char.
      
      Extended background:
      
      String.prototype.replace is (roughly) structured as follows:
      
      * Check if {searchValue} has a @@replace Symbol, and delegate to that if
        so. We currently implement efficient fast paths when {searchValue} is
        a String or a fast RegExp.
      * A specialized fast path for single-char {searchValue}, "long" subject
        string, and String {replaceValue} that do not contain '$' chars (yes,
        this fast path is very specialized).
      * Check for the location of the first match using StringIndexOf, and
        exit early if no match is found.
      * Finally build the return value, which is 'prefix + replacement +
        suffix', where replacement is either the result of calling {replaceValue}
        (if it is callable), or GetSubstitution(ToString({replaceValue}))
        otherwise.
      
      There's several spots that could be improved.
      
      StringIndexOf currently calls into C++ runtime for all but the simple
      1-byte, 1-char {searchValue} case. We need to finally add support for
      remaining cases.
      
      The runtime call to GetSubstitution can be skipped if the replacer
      string does not contain any '$' syntax. This CL handles that case.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2813843002
      Cr-Commit-Position: refs/heads/master@{#44606}
      f4ba786d
    • mic.besace's avatar
      Do not print enforcing Ignition and TurboFan when --turbo is on · a5f91b3a
      mic.besace authored
      BUG=
      
      Review-Url: https://codereview.chromium.org/2757543004
      Cr-Commit-Position: refs/heads/master@{#44605}
      a5f91b3a
    • pwnall's avatar
      Add nogncheck to gtest/gtest_prod.h includes. · 53f13a09
      pwnall authored
      This is necessary to appease "gn check" if gtest_prod.h becomes a part
      of the Chromium checkout, instead of a third-party repository brought
      over by Chromium's DEPS. The file is already listed in v8's DEPS, but gn
      does not use DEPS as an input.
      
      BUG=chromium:630705
      
      Review-Url: https://codereview.chromium.org/2807353002
      Cr-Commit-Position: refs/heads/master@{#44604}
      53f13a09
    • bmeurer's avatar
      [turbofan] Properly represent the float64 hole. · 8c0c5e81
      bmeurer authored
      The hole NaN should also have proper Type::Hole, and not silently hide
      in the Type::Number. This way we can remove all the special casing for
      the hole NaN, and we also finally get the CheckNumber right.
      
      This also allows us to remove some ducktape from the Deoptimizer, as for
      escape analyzed FixedDoubleArrays we always pass the hole value now to
      represent the actual holes.
      
      Also-By: jarin@chromium.org
      BUG=chromium:684208,chromium:709753,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2814013003
      Cr-Commit-Position: refs/heads/master@{#44603}
      8c0c5e81
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Avoid double parsing of locals · 366f7530
      Clemens Hammacher authored
      The local variables were parsed two times, which in fact doubled the
      amount of local variables allocated for each called function.
      This was costing memory and performance. As the additional local
      variables were never used, we did not recognize this before.
      
      Add a test case for locals and stack values of interpreted frames.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: Ie5cb8d8f5441edee6abb46aa6bebef4a033d582b
      Reviewed-on: https://chromium-review.googlesource.com/474749
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44602}
      366f7530
    • Michael Achenbach's avatar
      [test] Fix sanitizer-coverage default options for gyp builds · 17c28684
      Michael Achenbach authored
      This was missing in:
      TBR=vogelheim@chromium.org
      
      Bug: chromium:710409
      
      TBR=vogelheim@chromium.org
      NOTRY=true
      Bug: chromium:710409
      
      Change-Id: Ic4b59550e358860cd10adf3d5137342ff7e862a3
      Reviewed-on: https://chromium-review.googlesource.com/475831
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44601}
      17c28684
    • 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
  2. 11 Apr, 2017 23 commits