1. 14 Jun, 2016 2 commits
  2. 13 Jun, 2016 2 commits
  3. 08 Jun, 2016 1 commit
    • gsathya's avatar
      Revert "Revert of [builtins] Properly optimize TypedArray/DataView accessors.... · 3c927e07
      gsathya authored
      Revert "Revert of [builtins] Properly optimize TypedArray/DataView accessors. (patchset #3 id:40001 of https://codereview.chromium.org/2042013003/ )"
      
      This reverts commit d3a43e47.
      
      This patch also adds typed_array_fun and typed_array_protoype to the
      native context. These are used in InstallTypedArray to set up the
      prototype chain correctly for each typed array sub class. This removes
      the need to later monkey patch them prototype chain in typedarray.js.
      This mechanism is also used to get hold of the TypedArray in
      typedarray.js, removing the need for a global TypedArray.
      
      This patch updates CallRuntime.golden to account for the two extra
      native runtime calls. This patch also fixes some formatting issues (by
      running git cl format).
      
      BUG=chromium:579905, chromium:593634, v8:4085, v8:5073
      
      Review-Url: https://codereview.chromium.org/2046333002
      Cr-Commit-Position: refs/heads/master@{#36811}
      3c927e07
  4. 07 Jun, 2016 2 commits
    • machenbach's avatar
      Revert of [builtins] Properly optimize TypedArray/DataView accessors.... · d3a43e47
      machenbach authored
      Revert of [builtins] Properly optimize TypedArray/DataView accessors. (patchset #3 id:40001 of https://codereview.chromium.org/2042013003/ )
      
      Reason for revert:
      Blink:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7296
      
      Original issue's description:
      > [builtins] Properly optimize TypedArray/DataView accessors.
      >
      > The following getters were moved to the TypedArray/DataView prototype
      > chain with ES2015, and hence need different treatment now:
      >
      > - DataView.prototype.buffer
      > - DataView.prototype.byteLength
      > - DataView.prototype.byteOffset
      > - TypedArray.prototype.buffer
      > - TypedArray.prototype.byteLength
      > - TypedArray.prototype.byteOffset
      > - TypedArray.prototype.length
      >
      > Instead of having special magic on the LoadIC in the IC system and the
      > optimizing compilers, as we used to do before (and which we got rid of
      > already), we just treat those as normal accessors and make them
      > recognizable via the BuiltinFunctionId mechanism. This allows us to
      > remove some of the additional magic from the IC subsystem, and just
      > extend the BuiltinFunctionId mechanism in Crankshaft slightly to cover
      > these cases too (TurboFan doesn't yet support accessors, but that will
      > be fixed soonish anyways).
      >
      > This addresses most of the 15-20% regression we saw on the Octane
      > GameBoy emulator benchmark.
      >
      > BUG=chromium:579905,chromium:593634,v8:4085,v8:5073
      > R=yangguo@chromium.org
      >
      > Committed: https://crrev.com/1ef737026565ea2becc84f30cfd432e581d50c6b
      > Cr-Commit-Position: refs/heads/master@{#36782}
      
      TBR=yangguo@chromium.org,bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:579905,chromium:593634,v8:4085,v8:5073
      
      Review-Url: https://codereview.chromium.org/2039093005
      Cr-Commit-Position: refs/heads/master@{#36783}
      d3a43e47
    • bmeurer's avatar
      [builtins] Properly optimize TypedArray/DataView accessors. · 1ef73702
      bmeurer authored
      The following getters were moved to the TypedArray/DataView prototype
      chain with ES2015, and hence need different treatment now:
      
      - DataView.prototype.buffer
      - DataView.prototype.byteLength
      - DataView.prototype.byteOffset
      - TypedArray.prototype.buffer
      - TypedArray.prototype.byteLength
      - TypedArray.prototype.byteOffset
      - TypedArray.prototype.length
      
      Instead of having special magic on the LoadIC in the IC system and the
      optimizing compilers, as we used to do before (and which we got rid of
      already), we just treat those as normal accessors and make them
      recognizable via the BuiltinFunctionId mechanism. This allows us to
      remove some of the additional magic from the IC subsystem, and just
      extend the BuiltinFunctionId mechanism in Crankshaft slightly to cover
      these cases too (TurboFan doesn't yet support accessors, but that will
      be fixed soonish anyways).
      
      This addresses most of the 15-20% regression we saw on the Octane
      GameBoy emulator benchmark.
      
      BUG=chromium:579905,chromium:593634,v8:4085,v8:5073
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2042013003
      Cr-Commit-Position: refs/heads/master@{#36782}
      1ef73702
  5. 01 Jun, 2016 1 commit
  6. 19 May, 2016 1 commit
    • adamk's avatar
      Remove now-incorrect DataView accessor optimization · de7d47e2
      adamk authored
      In ES2015, the "byteLength" and "byteOffset" properties of DataViews are
      getters on the prototype, so the previously-used strategy of special-casing
      them using only the receiver map is invalid.
      
      A future CL will need to use the same strategy which will be taken for
      TypedArray "length", "byteLength", and "byteOffset": adding a prototype
      chain check.
      
      BUG=v8:5018, chromium:593634
      
      Review-Url: https://codereview.chromium.org/1984043002
      Cr-Commit-Position: refs/heads/master@{#36382}
      de7d47e2
  7. 18 Feb, 2016 1 commit
  8. 17 Feb, 2016 1 commit
  9. 16 Feb, 2016 1 commit
  10. 02 Feb, 2016 1 commit
    • jarin's avatar
      Remove the template magic from types.(h|cc), remove types-inl.h. · ef35f11c
      jarin authored
      This CL removes the Config templatization from the types. It is not
      necessary anymore, after the HeapTypes have been removed.
      
      The CL also changes the type hierarchy - the specific type kinds are
      not inner classes of the Type class and they do not inherit from Type.
      This is partly because it seems impossible to make this work without
      templates. Instead, a new TypeBase class is introduced and all the
      structural (i.e., non-bitset) types inherit from it.
      
      The bitset type still requires the bit-munging hack and some nasty
      reinterpret-casts to pretend bitsets are of type Type*. Additionally,
      there is now the same hack for TypeBase - all pointers to the sub-types
      of TypeBase are reinterpret-casted to Type*. This is to keep the type
      constructors in inline method definitions (although it is unclear how
      much that actually buys us).
      
      In future, we would like to move to a model where we encapsulate Type*
      into a class (or possibly use Type where we used to use Type*). This
      would loosen the coupling between bitset size and pointer size, and
      eventually we would be able to have more bits.
      
      TBR=bradnelson@chromium.org
      
      Review URL: https://codereview.chromium.org/1655833002
      
      Cr-Commit-Position: refs/heads/master@{#33656}
      ef35f11c
  11. 26 Jan, 2016 1 commit
    • jarin's avatar
      Replace HeapType with a non-templated FieldType class. · cfaeb63b
      jarin authored
      This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
      
      The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
      
      TBR=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1636013002
      
      Cr-Commit-Position: refs/heads/master@{#33521}
      cfaeb63b
  12. 19 Nov, 2015 1 commit
  13. 18 Nov, 2015 2 commits
    • bmeurer's avatar
      [turbofan] Decouple inlining and native context specialization. · 9b14e5bb
      bmeurer authored
      Retrieve the native context/global object from the Node being
      specialized in the JSNativeContextSpecialization and the
      JSGlobalObjectSpecialization classes. For this we introduce two
      new methods NodeProperties::GetSpecializationNativeContext and
      NodeProperties::GetSpecializationGlobalObject, which walk up
      the context chain and might in the end take the native context
      from the outermost activation (if native context specialization
      is enabled). This allows us to run the native context specialization
      pass as part of the inlining phase without hacking some of that into
      the JSInliner.
      
      Also refactor the NodeProperties::GetSpecializationContext method
      that was previously local to the JSContextSpecialization.
      
      Also refactor two other oddities in JSNativeContextSpecialization.
      
      R=jarin@chromium.org
      BUG=v8:4470, v8:4493
      LOG=n
      
      Review URL: https://codereview.chromium.org/1451143005
      
      Cr-Commit-Position: refs/heads/master@{#32076}
      9b14e5bb
    • bmeurer's avatar
      [turbofan] Add support for special JSArrayBufferView accessors. · 3e328bf2
      bmeurer authored
      Lower access to byteOffset and byteLength getters on JSArrayBufferViews
      and to length on JSTypedArrays. This requires a check to see whether the
      backing JSArrayBuffer was neutered.
      
      R=mstarzinger@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1453653003
      
      Cr-Commit-Position: refs/heads/master@{#32070}
      3e328bf2
  14. 17 Nov, 2015 1 commit
  15. 16 Nov, 2015 2 commits
  16. 11 Nov, 2015 1 commit
  17. 03 Nov, 2015 2 commits
  18. 02 Nov, 2015 2 commits
  19. 30 Oct, 2015 2 commits