1. 10 Jul, 2020 1 commit
  2. 12 Dec, 2019 1 commit
  3. 11 Nov, 2019 2 commits
  4. 07 Nov, 2019 1 commit
  5. 16 Sep, 2019 1 commit
  6. 13 Sep, 2019 1 commit
  7. 05 Sep, 2019 1 commit
  8. 28 Aug, 2019 1 commit
  9. 23 Aug, 2019 1 commit
    • Georg Schmid's avatar
      [turbofan] Relax double const store invariant in load elim. for literals · 7fd19228
      Georg Schmid authored
      Even when a field is marked const, we may emit multiple consecutive in-literal stores to that field. That is, in 'JSNativeContextSpecialization::BuildPropertyStore', when the access mode is 'kStoreInLiteral' and we are accessing a const field, we may produce a StoreField node, even though another StoreField (that stores something other than 'Uninitialized') to the same const field dominates it. This appears to be sound, since earlier stores to literals cannot be observed anyways.
      
      Unfortunately this behavior conflicts with the double const store invariant in load elimination: Roughly speaking, we assume that load elimination may never observe two consecutive const stores to the same field on the same object.
      
      The apparent solution would be to treat 'kStoreInLiteral' accesses like regular 'kStore' accesses: For consecutive stores to const properties we don't emit StoreField, but instead emit code that checks whether the value about to be written is equivalent to the previously written one, and otherwise deopt ('DeoptimizeReason::kWrongValue'). Unfortunately this turns out impractical, since for 'kStoreInLiteral' accesses we can't easily decide whether we're dealing with the first such store or one of the consecutive ones. Also see this abandoned CL: https://chromium-review.googlesource.com/c/v8/v8/+/1762020.
      
      This CL instead adds an exception to the invariant in load elimination. We track whether a store arose from a 'kStoreInLiteral' access, and use this information when visiting StoreField nodes in load elimination.
      
      R=neis@chromium.org, tebbi@chromium.org
      
      Bug: chromium:987205
      Change-Id: I8829752aa0637e9599677d20aad2d706d40d7fe6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763535Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Schmid <gsps@google.com>
      Cr-Commit-Position: refs/heads/master@{#63385}
      7fd19228
  10. 16 Aug, 2019 2 commits
    • Georg Schmid's avatar
      [turbofan] Track field owner maps during load elimination · f85826ea
      Georg Schmid authored
      This CL adds additional information in PropertyAccessInfos and FieldAccesses about the map that introduced the accessed field. We use this information to prevent load elimination from incorrectly optimizing certain accesses marked const.
      
      Prior to this CL, load elimination simply stored information about eliminatable field accesses based on objects (identified by nodes in the graph) and offsets (i.e., statically known ones). In the presence of const stores and loads this is insufficient, since a single object (in the above sense) may contain distinct *const* properties at the same offset throughout its lifetime. As an example, consider the following piece of code:
      
          let obj = {};
          obj.a = 0;
          obj[1024] = 1;  // An offset of >=1024 forces an elements-kind transition
          delete obj.a;
          obj.b = 2;
          assertEquals(obj.b, 2);
      
      In this scenario, *both* the first ('obj.a = 0') and the second ('obj.b = 2') store to a field will be marked const by the runtime. The reason that storing to 'a' above ends up being marked const, is that 'a' before and after the elements-kind transition is encoded in separate transition trees. Removing 'a' ('delete obj.a') only invalidates const-ness in the dictionary-elements transition tree; not the holey-elements one used at the time of 'obj.a = 0'.
      
      The above situation on its own violates an invariant in load elimination. Namely, we assume that for the same object and offset, we will never encounter two const stores. One can extend the above snippet to coax load-elimination into producing incorrect results. For instance, by "hiding" 'obj.b = 2' in an unoptimized function call, the consecutive load from 'b' will incorrectly produce 0, violating the assert.
      
      R=neis@chromium.org, tebbi@chromium.org
      
      Bug: chromium:980183, chromium:983764
      Change-Id: I576a9c7efd416fa9db6daff1f42d483e4bd369b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751346
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63226}
      f85826ea
    • Tobias Tebbi's avatar
      [compiler] support bigger representations in load elimination · 1ec03946
      Tobias Tebbi authored
      This removes the restriction on load elimination to only track fields
      of representations with kTaggedSize, and instead also allows fields with
      representations using multiples of kTaggedSize (that is, Float64 and Word64
      on pointer-compressed or 32-bit platforms).
      
      In order not to regress JIT-compile time for the common case of
      kTaggedSize-sized fields, we maintain information for bigger fields multiple
      times, once for each kTaggedSize-multiple offset that covers it. By checking
      that all copies of this information are still there when reading from the
      load elimination state, updates to the load elimination state don't need to
      take special care of bigger fields.
      
      Change-Id: I9b5f3d2d6e3b4f145c20d33fbc764869bf50a365
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752843
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63222}
      1ec03946
  11. 24 Jul, 2019 1 commit
    • Jakob Gruber's avatar
      [compiler] Allocate in a temporary zone inside ComputeLoopState · d267c337
      Jakob Gruber authored
      Even in the most basic case (the task queue only ever contains a single
      element), this function triggers ~4KB in zone allocations. These
      allocations are basically lost and can never be reused. Avoid this by
      allocating inside a new temporary zone that is only alive during the
      ComputeLoopState function call.
      
      This reduces allocation size for the zone used during load elimination
      from ~30KB to ~15KB when compiling a trivial for-loop example.
      
      An alternative solution would be to switch to something similar to
      SmallVector (which uses a statically-sized stack storage before
      switching to heap allocations), but based on zones instead of malloc.
      
      Bug: v8:9427,v8:6150
      Change-Id: Ic25abe6d48ac718c9ced2f9ef581f244030980fa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714869
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62883}
      d267c337
  12. 15 Jul, 2019 1 commit
  13. 11 Jun, 2019 1 commit
  14. 05 Jun, 2019 1 commit
  15. 04 Jun, 2019 1 commit
  16. 28 May, 2019 1 commit
  17. 27 May, 2019 2 commits
  18. 24 May, 2019 1 commit
  19. 23 May, 2019 2 commits
  20. 15 May, 2019 1 commit
  21. 10 May, 2019 1 commit
  22. 08 May, 2019 1 commit
  23. 02 May, 2019 1 commit
  24. 13 Mar, 2019 1 commit
  25. 25 Feb, 2019 1 commit
  26. 04 Feb, 2019 1 commit
  27. 19 Dec, 2018 1 commit
  28. 21 Nov, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Apply duct-tape to load elimination · b28637b4
      Sigurd Schneider authored
      Load elimination is running together with to dead code elimination, the
      latter of which might eliminate allocations (in particular FinishRegion
      nodes). These are treated as alias nodes by load elimination, and load
      elimination does not immediatelly learn that a node has been disconnected.
      This causes load elimination to access the inputs of dead code eliminated
      nodes while resolving renames, which causes nullptr dereferences.
      
      This CL modifies load elimination to not resolve to a nullptr alias but
      simply stop before that.
      
      Change-Id: If4cef061c7c0e25f353727c9e27f790439b0beb5
      Bug: chromium:906406
      Reviewed-on: https://chromium-review.googlesource.com/c/1346491
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57688}
      b28637b4
  29. 21 Sep, 2018 1 commit
    • Jakob Kummerow's avatar
      Fix building with GCC 7.x and 8.x · 9ed4b965
      Jakob Kummerow authored
      GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class
      either derives from a class or has a member field of a type that
      was declared in an anonymous namespace.
      It is also opposed (-Werror=attributes) to visibility attributes
      being defined at explicit template instantiations.
      GCC 8.x further has reservations (-Werror=class-memaccess) about
      letting memset/memcpy modify areas within non-POD objects.
      
      Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a
      Reviewed-on: https://chromium-review.googlesource.com/1208306
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56106}
      9ed4b965
  30. 17 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Cleanup JSArrayBuffer and TurboFan's handling of neutering. · beebb236
      Benedikt Meurer authored
      Cleanup the JSArrayBuffer bit fields to use the proper object macros
      that are now otherwise used consistently across the code base. Also
      change TurboFan to consistently bailout when it sees an array buffer
      that was previously neutered, so that the generic path / builtins are
      again the chokepoints for the spec violations (the fact that we don't
      always raise exceptions when we see a neutered array buffer), except
      for the ArrayBufferView accessor inlining in the JSCallReducer, where
      we still turn the values into zero (because we don't have access to
      a CALL_IC speculation guard in the common case).
      
      This also removes the ArrayBufferWasNeutered simplified operator, and
      does regular LoadField + Number bitwise operations instead, which is
      good enough and allows us to get rid of a lot of unnecessary complexity.
      
      Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178
      Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947
      Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55958}
      beebb236
  31. 24 Aug, 2018 4 commits
    • Benedikt Meurer's avatar
      [turbofan] Handle CheckHeapObject as rename in LoadElimination. · e81480cd
      Benedikt Meurer authored
      Thus far the LoadElimination didn't consider CheckHeapObject a renaming
      operation and would therefore miss opportunities to eliminate redundant
      loads or map checks where the input is not checked for sminess in all
      cases. This kind of pattern is very common with code that results from
      builtin inlining in JSCallReducer, as here we don't unconditionally
      insert CheckHeapObject nodes if we can tell from the graph that the
      receiver already has a certain map (by walking the effect chain
      upwards).
      
      Bug: v8:8070
      Change-Id: I980f382205757a754f93a5741de1ee08b75ee070
      Reviewed-on: https://chromium-review.googlesource.com/1188129Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55408}
      e81480cd
    • Benedikt Meurer's avatar
      [turbofan] Handle LoadField with type mismatch in LoadElimination. · 318e5230
      Benedikt Meurer authored
      This allows to replace redundant LoadField's whose type doesn't match
      the type of the replacement, by just turning those LoadField's into
      TypeGuard's.
      
      Bug: v8:8070
      Change-Id: Ia329bb536f8829be27e070e90e9eaae0618dac7a
      Reviewed-on: https://chromium-review.googlesource.com/1188131Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55407}
      318e5230
    • Benedikt Meurer's avatar
      [turbofan] Fix --trace-turbo-load-elimination. · cfd752af
      Benedikt Meurer authored
      The LoadElimination must be able to print Maps, so we need to allow
      handle dereferencing here.
      
      Change-Id: Id39a6db5a4f40ec6212404b3aa30a36fdd1ba57e
      Reviewed-on: https://chromium-review.googlesource.com/1188127
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55374}
      cfd752af
    • Benedikt Meurer's avatar
      [turbofan] Handle initializing stores properly for alias analysis. · 280361d2
      Benedikt Meurer authored
      In LoadElimination leverage the fact that initializing stores (i.e.
      stores to freshly allocated objects) cannot touch existing objects,
      since the object can only escape once it's fully initialized and
      then all accesses will happen on the FinishRegion node instead of
      the naked Allocate node.
      
      This helps to eliminate the redundant map checks and "length" accesses
      to arrays, since TurboFan now knows that the iterated array cannot
      alias with neither the freshly allocated ArrayIterator nor the
      freshly allocated IterResultObject instances. This improves the times
      on the benchmark in the tracking bug from
      
        console.timeEnd: forOf, 188.111000
        console.timeEnd: traditional, 116.380000
        console.timeEnd: forOf, 170.721000
        console.timeEnd: traditional, 108.209000
        console.timeEnd: forOf, 168.491000
        console.timeEnd: traditional, 108.839000
      
      to
      
        console.timeEnd: forOf, 192.501000
        console.timeEnd: traditional, 106.909000
        console.timeEnd: forOf, 138.364000
        console.timeEnd: traditional, 103.232000
        console.timeEnd: forOf, 138.755000
        console.timeEnd: traditional, 102.928000
      
      when running with untrusted code mitigations turned off, and thus
      corresponds to a ~18% performance improvement, roughly cutting the
      performance difference between the traditional for loop and the for..of
      loop in half.
      
      Besides for..of loops this will also help with array destructuring
      patterns where TurboFan also emitted redundant map checks on the array
      and didn't eliminate the redundant "length" accesses.
      
      Bug: v8:8070
      Change-Id: Iab283247f6d304d1e3c7c147f32ab957577aad21
      Reviewed-on: https://chromium-review.googlesource.com/1188124Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55373}
      280361d2
  32. 15 Jun, 2018 1 commit
  33. 14 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored
      This is a reland of 0909dbe3.
      Added missing V8_EXPORT_PRIVATE to AndroidLogStream.
      
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      >
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      >
      > R=mstarzinger@chromium.org
      >
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      Bug: v8:7820
      Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
      Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257