1. 03 Mar, 2016 1 commit
    • bmeurer's avatar
      [runtime] Rename IsUndetectableObject to IsUndetectable. · 0b3e436a
      bmeurer authored
      This is more consistent with the current naming scheme (i.e. IsCallable
      for callable bit on map, IsConstructor for constructor bit on map, and
      now IsUndetectable for undetectable bit on map).
      
      Also simplify the fallthrough case for Object::Equals, because we don't
      need to check for Null or Undefined or Undetectable, as both Null and
      Undefined already have the undetectable bit set on their maps.
      
      R=machenbach@chromium.org
      
      Review URL: https://codereview.chromium.org/1756413003
      
      Cr-Commit-Position: refs/heads/master@{#34458}
      0b3e436a
  2. 26 Feb, 2016 1 commit
    • bmeurer's avatar
      [ic] Unify undetectable abstract equality comparison. · 1b821f2f
      bmeurer authored
      The treatment of different undetectable objects was inconsistent after
      the latest changes to the undetectable bit in the maps. Given two
      different undetectable JSObjects a and b, a monomorphic CompareIC would
      say false for a == b, while the rest of the system (including the
      generic case for the CompareIC) would say true.
      
      The fix is rather straight-forward: We just go generic on a CompareIC
      once we see an undetectable JSObject.
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1735863004
      
      Cr-Commit-Position: refs/heads/master@{#34315}
      1b821f2f
  3. 16 Feb, 2016 1 commit
  4. 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
  5. 07 Dec, 2015 1 commit
  6. 01 Dec, 2015 1 commit
  7. 09 Nov, 2015 1 commit
    • bmeurer's avatar
      [builtins] Introduce specialized Call/CallFunction builtins. · 7c3396d0
      bmeurer authored
      Introduce receiver conversion mode specialization for the Call and
      CallFunction builtins, so we can specialize the builtin functionality
      (actually an optimization only) based on static information from the
      callsite (this is basically a superset of the optimizations that were
      available with the CallFunctionStub and CallICStub, except that these
      optimizations are correct now).
      
      This fixes a regression introduced by the removal of CallFunctionStub,
      for programs that call a lot.
      
      R=yangguo@chromium.org
      BUG=chromium:552244
      LOG=n
      
      Review URL: https://codereview.chromium.org/1436493002
      
      Cr-Commit-Position: refs/heads/master@{#31871}
      7c3396d0
  8. 05 Nov, 2015 1 commit
  9. 22 Sep, 2015 1 commit
    • bmeurer's avatar
      [ic] Introduce BOOLEAN state for CompareIC. · 10c5f2e8
      bmeurer authored
      Slow path for relational comparison of boolean primitive values
      now goes through the runtime, which made the slow path even
      slower than it already was. So in order to repair the regression,
      we just track boolean feedback for comparisons and use that
      to generate decent code in Crankshaft (not the best possible
      code, but good enough for Crankshaft; TurboFan will be able
      to do better on that).
      
      R=jarin@chromium.org
      BUG=chromium:534200
      LOG=n
      
      Review URL: https://codereview.chromium.org/1347063004
      
      Cr-Commit-Position: refs/heads/master@{#30860}
      10c5f2e8
  10. 21 Sep, 2015 1 commit
    • bmeurer's avatar
      [ic] Also collect known map for relational comparison. · e56f265f
      bmeurer authored
      Previously we only collected the known map for equality comparisons. But
      if we also collect it for relational comparisons, we can inline a fast
      path of ToPrimitive on the objects, which is especially interesting
      since both sides have the same map.
      
      For now we only inline a very limited subset of ToPrimitive in
      Crankshaft, which is when the receiver map (and its prototype chain)
      doesn't have @@toPrimitive, and both valueOf and toString are the
      default versions on the %ObjectPrototype%. In this case the relational
      comparison would reduce to a string comparison of "[object CLASS]" with
      itself and so we can reduce that to a boolean constant plus map checks
      on both left and right hand side, plus code dependencies on the
      prototype chain. This repairs the regression on box2d.
      
      R=jkummerow@chromium.org
      BUG=chromium:534200
      LOG=n
      
      Review URL: https://codereview.chromium.org/1355113002
      
      Cr-Commit-Position: refs/heads/master@{#30852}
      e56f265f
  11. 14 Aug, 2015 1 commit
  12. 30 Jun, 2015 1 commit
  13. 08 Jun, 2015 1 commit
  14. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1162993006
      
      Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  15. 03 Jun, 2015 1 commit
  16. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1131783003
      
      Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  17. 01 Jun, 2015 1 commit
  18. 24 Apr, 2015 1 commit
  19. 02 Mar, 2015 2 commits
  20. 05 Feb, 2015 1 commit
  21. 30 Jan, 2015 1 commit
  22. 27 Nov, 2014 1 commit
  23. 28 Oct, 2014 3 commits
  24. 20 Oct, 2014 1 commit
  25. 30 Sep, 2014 1 commit
  26. 16 Sep, 2014 1 commit