1. 07 Oct, 2015 1 commit
  2. 06 Oct, 2015 1 commit
  3. 05 Oct, 2015 1 commit
  4. 02 Oct, 2015 3 commits
    • danno's avatar
      Re-reland: Remove register index/code indirection · 5cf1c0bc
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      Cr-Commit-Position: refs/heads/master@{#30913}
      
      Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
      Cr-Commit-Position: refs/heads/master@{#31075}
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#31087}
      5cf1c0bc
    • danno's avatar
      Revert of Reland: Remove register index/code indirection (patchset #20... · 00e07b00
      danno authored
      Revert of Reland: Remove register index/code indirection (patchset #20 id:380001 of https://codereview.chromium.org/1287383003/ )
      
      Reason for revert:
      Failures on MIPS
      
      Original issue's description:
      > Remove register index/code indirection
      >
      > Previous to this patch, both the lithium and TurboFan register
      > allocators tracked allocated registers by "indices", rather than
      > the register codes used elsewhere in the runtime. This patch
      > ensures that codes are used everywhere, and in the process cleans
      > up a bunch of redundant code and adds more structure to how the
      > set of allocatable registers is defined.
      >
      > Some highlights of changes:
      >
      > * TurboFan's RegisterConfiguration class moved to V8's top level
      >   so that it can be shared with Crankshaft.
      > * Various "ToAllocationIndex" and related methods removed.
      > * Code that can be easily shared between Register classes on
      >   different platforms is now shared.
      > * The list of allocatable registers on each platform is declared
      >   as a list rather than implicitly via the register index <->
      >   code mapping.
      >
      > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      > Cr-Commit-Position: refs/heads/master@{#30913}
      >
      > Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
      > Cr-Commit-Position: refs/heads/master@{#31075}
      
      TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1380863004
      
      Cr-Commit-Position: refs/heads/master@{#31083}
      00e07b00
    • danno's avatar
      Remove register index/code indirection · 7b7a8205
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      Cr-Commit-Position: refs/heads/master@{#30913}
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#31075}
      7b7a8205
  5. 01 Oct, 2015 2 commits
    • bmeurer's avatar
      [es6] Fix missing bits for full @@toPrimitive support. · 2a0759d3
      bmeurer authored
      Introduce %_ToNumber intrinsic, which just calls to the existing
      ToNumberStub, and remove all uses of our custom JavaScript plus
      intrinsics based ToNumber and friends.
      
      Also replace the TO_NUMBER_INLINE macro with TO_NUMBER,
      which is currently a wrapper for %_ToNumber. Newly written JS
      code should use TO_NUMBER (similar to TO_STRING, TO_INT32,
      and friends).
      
      Also finally remove the DefaultString/DefaultNumber builtins, which
      are basically the ES5 version of ToPrimitive. Now all code uses the
      ES6 version, which is implemented in Object::ToPrimitive and
      JSReceiver::ToPrimitive in C++.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      R=jarin@chromium.org
      BUG=v8:4307
      LOG=n
      
      Review URL: https://codereview.chromium.org/1384443002
      
      Cr-Commit-Position: refs/heads/master@{#31054}
      2a0759d3
    • ishell's avatar
      Distinction between FeedbackVectorICSlot and FeedbackVectorSlot eliminated. · 90998947
      ishell authored
      This CL also allows to use arbitrary number of feedback vector elements for particular slot kind.
      
      Review URL: https://codereview.chromium.org/1370303004
      
      Cr-Commit-Position: refs/heads/master@{#31050}
      90998947
  6. 29 Sep, 2015 2 commits
    • mvstanton's avatar
      Introduce LiteralsArray to hide it's implementation. · d8cdd695
      mvstanton authored
      The LiteralsArray will soon hold a type feedback vector. Code treats it as an
      ordinary fixed array, and needs to stop that.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1374723002
      
      Cr-Commit-Position: refs/heads/master@{#31000}
      d8cdd695
    • bmeurer's avatar
      [es6] Introduce %ToInteger and %ToLength. · 93b2b262
      bmeurer authored
      This adds ES6 compliant Object::ToInteger, Object::ToInt32,
      Object::ToUint32 and Object::ToLength, and replaces the old
      Execution wrappers of those abstract operations (which were
      not using the correct ToPrimitive).
      
      This also introduces proper %ToInteger and %ToLength runtime
      entries, with a fast path %_ToInteger supported in fullcodegen
      and Crankshaft (for now). Internal JavaScript code should use
      TO_INTEGER and TO_LENGTH respectively.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      BUG=v8:4307
      LOG=n
      
      Review URL: https://codereview.chromium.org/1378533002
      
      Cr-Commit-Position: refs/heads/master@{#30993}
      93b2b262
  7. 28 Sep, 2015 2 commits
  8. 24 Sep, 2015 5 commits
    • danno's avatar
      Revert of Remove register index/code indirection (patchset #17 id:320001 of... · 3ac27431
      danno authored
      Revert of Remove register index/code indirection (patchset #17 id:320001 of https://codereview.chromium.org/1287383003/ )
      
      Reason for revert:
      Failures on greedy RegAlloc, Fuzzer
      
      Original issue's description:
      > Remove register index/code indirection
      >
      > Previous to this patch, both the lithium and TurboFan register
      > allocators tracked allocated registers by "indices", rather than
      > the register codes used elsewhere in the runtime. This patch
      > ensures that codes are used everywhere, and in the process cleans
      > up a bunch of redundant code and adds more structure to how the
      > set of allocatable registers is defined.
      >
      > Some highlights of changes:
      >
      > * TurboFan's RegisterConfiguration class moved to V8's top level
      >   so that it can be shared with Crankshaft.
      > * Various "ToAllocationIndex" and related methods removed.
      > * Code that can be easily shared between Register classes on
      >   different platforms is now shared.
      > * The list of allocatable registers on each platform is declared
      >   as a list rather than implicitly via the register index <->
      >   code mapping.
      >
      > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      > Cr-Commit-Position: refs/heads/master@{#30913}
      
      TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1365073002
      
      Cr-Commit-Position: refs/heads/master@{#30914}
      3ac27431
    • danno's avatar
      Remove register index/code indirection · 80bc6f6e
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#30913}
      80bc6f6e
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8fe3ac07
      bmeurer authored
      There was already a bit on the Map named "function with prototype",
      which basically meant that the Map was a map for a JSFunction that could
      be used as a constructor. Now this CL generalizes that bit to
      IsConstructor, which says that whatever (Heap)Object you are looking at
      can be used as a constructor (i.e. the bit is also set for bound
      functions that can be used as constructors and proxies that have a
      [[Construct]] internal method).
      
      This way we have a single chokepoint for IsConstructor checking, which
      allows us to get rid of the various ways in which we tried to guess
      whether something could be used as a constructor or not.
      
      Drive-by-fix: Renamed IsConstructor on FunctionKind to
      IsClassConstructor to resolve the weird name clash, and the
      IsClassConstructor name also matches the spec.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      R=jarin@chromium.org, rossberg@chromium.org
      BUG=v8:4413, v8:4430
      LOG=n
      
      Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
      Cr-Commit-Position: refs/heads/master@{#30900}
      
      Review URL: https://codereview.chromium.org/1358423002
      
      Cr-Commit-Position: refs/heads/master@{#30902}
      8fe3ac07
    • bmeurer's avatar
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001... · 656ebdce
      bmeurer authored
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ )
      
      Reason for revert:
      Failed on Fuzzer and MIPS bot.
      
      Original issue's description:
      > [es6] Introduce spec compliant IsConstructor.
      >
      > There was already a bit on the Map named "function with prototype",
      > which basically meant that the Map was a map for a JSFunction that could
      > be used as a constructor. Now this CL generalizes that bit to
      > IsConstructor, which says that whatever (Heap)Object you are looking at
      > can be used as a constructor (i.e. the bit is also set for bound
      > functions that can be used as constructors and proxies that have a
      > [[Construct]] internal method).
      >
      > This way we have a single chokepoint for IsConstructor checking, which
      > allows us to get rid of the various ways in which we tried to guess
      > whether something could be used as a constructor or not.
      >
      > Drive-by-fix: Renamed IsConstructor on FunctionKind to
      > IsClassConstructor to resolve the weird name clash, and the
      > IsClassConstructor name also matches the spec.
      >
      > R=jarin@chromium.org, rossberg@chromium.org
      > BUG=v8:4430
      > LOG=n
      >
      > Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
      > Cr-Commit-Position: refs/heads/master@{#30900}
      
      TBR=jarin@chromium.org,rossberg@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4430
      
      Review URL: https://codereview.chromium.org/1360403002
      
      Cr-Commit-Position: refs/heads/master@{#30901}
      656ebdce
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8de4d935
      bmeurer authored
      There was already a bit on the Map named "function with prototype",
      which basically meant that the Map was a map for a JSFunction that could
      be used as a constructor. Now this CL generalizes that bit to
      IsConstructor, which says that whatever (Heap)Object you are looking at
      can be used as a constructor (i.e. the bit is also set for bound
      functions that can be used as constructors and proxies that have a
      [[Construct]] internal method).
      
      This way we have a single chokepoint for IsConstructor checking, which
      allows us to get rid of the various ways in which we tried to guess
      whether something could be used as a constructor or not.
      
      Drive-by-fix: Renamed IsConstructor on FunctionKind to
      IsClassConstructor to resolve the weird name clash, and the
      IsClassConstructor name also matches the spec.
      
      R=jarin@chromium.org, rossberg@chromium.org
      BUG=v8:4430
      LOG=n
      
      Review URL: https://codereview.chromium.org/1358423002
      
      Cr-Commit-Position: refs/heads/master@{#30900}
      8de4d935
  9. 23 Sep, 2015 1 commit
  10. 22 Sep, 2015 3 commits
  11. 21 Sep, 2015 3 commits
    • 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
    • bmeurer's avatar
      [crankshaft] Generalize PropertyAccessInfo to Name (so it can deal with symbols). · 704e3d80
      bmeurer authored
      This doesn't fix the performance regression mentioned by the bug yet,
      but is necessary cleanup to land the fix, and should be separated from
      the actual fix.
      
      R=jkummerow@chromium.org
      BUG=chromium:534200
      LOG=n
      
      Review URL: https://codereview.chromium.org/1345313005
      
      Cr-Commit-Position: refs/heads/master@{#30847}
      704e3d80
    • littledan's avatar
      Implement sloppy-mode block-defined functions (Annex B 3.3) · e5ff10d7
      littledan authored
      ES2015 specifies very particular semantics for functions defined in blocks.
      In strict mode, it is simply a lexical binding scoped to that block. In sloppy
      mode, in addition to that lexical binding, there is a var-style binding in
      the outer scope, which is overwritten with the local binding when the function
      declaration is evaluated, *as long as* introducing ths var binding would not
      create a var/let conflict in the outer scope.
      
      This patch implements the semantics by introducing a DelegateStatement, which
      is initially filled in with the EmptyStatement and overwritten with the
      assignment when the scope is closed out and it can be checked that there is
      no conflict.
      
      This patch is tested with a new mjsunit test, and I tried staging it and running
      test262, finding that the tests that we have disabled due to lack of Annex B
      support now pass.
      
      R=adamk,rossberg
      LOG=Y
      BUG=v8:4285
      
      Review URL: https://codereview.chromium.org/1332873003
      
      Cr-Commit-Position: refs/heads/master@{#30842}
      e5ff10d7
  12. 18 Sep, 2015 3 commits
  13. 16 Sep, 2015 1 commit
  14. 15 Sep, 2015 2 commits
  15. 14 Sep, 2015 1 commit
    • bmeurer's avatar
      [builtins] Remove STRING_ADD_LEFT and STRING_ADD_RIGHT builtins. · d90a4047
      bmeurer authored
      These builtins present an optimization for the general addition case,
      where one side is already known to be a string. Unfortunately this
      optimization is wrong in the presence of @@toPrimitive (there are some
      ideas how to implement a similar optimization using the prototype
      backpointer mechanism that jkummerow@ introduced earlier). So this
      also removes the broken %_IsStringWrapperSafeForDefaultValueOf, which is
      the key part of the optimization mentioned above.
      
      R=mstarzinger@chromium.org
      BUG=v8:4307
      LOG=n
      
      Review URL: https://codereview.chromium.org/1336273002
      
      Cr-Commit-Position: refs/heads/master@{#30707}
      d90a4047
  16. 10 Sep, 2015 5 commits
    • mvstanton's avatar
      Vector ICs: The Oracle needs to report feedback for the object literals and the count operation. · 752b0308
      mvstanton authored
      The refactoring is because it's awkward and error-prone to deterimine which IC slot an
      ObjectLiteralProperty uses for feedback. The fix is for each one to know it's own slot. In the
      numbering pass, we allocate slots for the ObjectLiteral, then hand out those slots into the
      properties.
      
      It adds one word to the ObjectLiteralProperty expression - I'm investigating if thats a
      problem.
      
      This changes makes compiling the object literal cleaner across the three compilers. Also, the
      slot allocation logic in ObjectLiteral::ComputeFeedbackRequirements() was refactoring to mimic
      the style in full-codegen. This is useful since it must remain in sync with
      FullCodegen::VisitObjectLiteral().
      
      Review URL: https://codereview.chromium.org/1321993004
      
      Cr-Commit-Position: refs/heads/master@{#30686}
      752b0308
    • bmeurer's avatar
      [runtime] Move binary operator fallbacks into the runtime. · a1b2ec60
      bmeurer authored
      Replace the ADD, SUB, etc. builtins with proper runtime implementations,
      and expose them as runtime calls that can be used by the code stubs and
      the interpreter (for now).
      
      Also remove all the support runtime functions for ADD, SUB and friends,
      namely %NumberAdd, %NumberSub, and so on.
      
      R=mstarzinger@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      
      Review URL: https://codereview.chromium.org/1333843002
      
      Cr-Commit-Position: refs/heads/master@{#30680}
      a1b2ec60
    • mvstanton's avatar
      Fix for v8:4380 introduced a regression in Octane crypto. · ebd16fd8
      mvstanton authored
      Narrowed the scope of the fix, to make a best effort to avoid DEOPT in
      case the hole is loaded, but not to permute the choice of a consolidated
      load in case that effort fails.
      
      BUG=chromium:530005
      LOG=N
      
      Review URL: https://codereview.chromium.org/1330233004
      
      Cr-Commit-Position: refs/heads/master@{#30677}
      ebd16fd8
    • cbruni's avatar
      Adding template parameter to PrototypeIterator GetCurrent · aacaafd0
      cbruni authored
      BUG=
      
      Review URL: https://codereview.chromium.org/1330153003
      
      Cr-Commit-Position: refs/heads/master@{#30676}
      aacaafd0
    • bmeurer's avatar
      [runtime] Sanitize %NewClosure runtime entries. · 6b3c070d
      bmeurer authored
      There are now two runtime entries %NewClosure and %NewClosure_Tenured,
      with the same signature (one parameter, the SharedFunctionInfo, and the
      context of the caller).
      
      Also remove the HFunctionLiteral special case instruction from Crankshaft,
      as HCallWithDescriptor with FastNewClosureStub or HCallRuntime with
      either %NewClosure or %NewClosure_Tenured can easily do that for you.
      
      Also remove the redundant context parameter from the JSCreateClosure
      operator, because every JS operator already takes a context input.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg
      
      Review URL: https://codereview.chromium.org/1329293003
      
      Cr-Commit-Position: refs/heads/master@{#30671}
      6b3c070d
  17. 09 Sep, 2015 2 commits
    • mvstanton's avatar
      Crankshaft: consolidated element loads always deopted on seeing the hole · 164f92d2
      mvstanton authored
      Update the consolidated load case to carefully chose the load mode
      based on the consolidated elements kind.
      
      BUG=v8:4380
      LOG=N
      
      Review URL: https://codereview.chromium.org/1329793003
      
      Cr-Commit-Position: refs/heads/master@{#30659}
      164f92d2
    • bmeurer's avatar
      [calls] Consistent call protocol for calls. · b37907ff
      bmeurer authored
      The number of actual arguments should always be available, there's no
      point in trying to optimize away a simple assignment of an immediate to
      a register before some calls.
      
      The main motivation is to have a consistent state at the beginning of every
      function. Currently the arguments register (i.e. rax or eax) either contains
      the number of arguments or some random garbage depending on whether
      the callsite decided that the callee might need the information or not.
      This causes trouble with runtime implementations of functions that
      do not set internal_formal_parameter_count to the DontAdaptArguments
      sentinel (we don't have any of those yet), but also makes it impossible
      to sanity check the arguments in the callee, because the callee doesn't
      know whether the caller decided to pass the number of arguments or
      random garbage.
      
      BUG=v8:4413
      LOG=n
      
      Review URL: https://codereview.chromium.org/1330033002
      
      Cr-Commit-Position: refs/heads/master@{#30648}
      b37907ff
  18. 08 Sep, 2015 1 commit
    • bmeurer's avatar
      [runtime] Replace many buggy uses of %_CallFunction with %_Call. · db2ba190
      bmeurer authored
      The semantics of the %_CallFunction intrinsic seem to be very unclear,
      which resulted in a lot of bugs. Especially the combination with
      %IsSloppyModeFunction is always a bug, because the receiver would be
      wrapped in the wrong context. So the %IsSloppyModeFunction helper is
      gone now, and many of the buggy uses of %_CallFunction are also
      eliminated.
      
      If you ever need to call something with a different receiver, then
      %_Call is your friend now. It does what you want and implements the
      call sequence fully (and correct).
      
      BUG=v8:4413
      LOG=n
      
      Review URL: https://codereview.chromium.org/1325573004
      
      Cr-Commit-Position: refs/heads/master@{#30634}
      db2ba190
  19. 04 Sep, 2015 1 commit