1. 21 Aug, 2015 19 commits
    • chunyang.dai's avatar
      X87: VectorICs: New interface descriptor for vector transitioning stores. · 6c404625
      chunyang.dai authored
      port cd351559 (r30284).
      
      original commit message:
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1303223002
      
      Cr-Commit-Position: refs/heads/master@{#30297}
      6c404625
    • chunyang.dai's avatar
      X87: Cleanup: Remove unncessary leave_frame parameter from stub cache. · 597cfc6e
      chunyang.dai authored
      port fe432e1a (r30250).
      
      original commit message:
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1303973004
      
      Cr-Commit-Position: refs/heads/master@{#30296}
      597cfc6e
    • rossberg's avatar
      [es6] Parameter scopes for sloppy eval · 365fd7bc
      rossberg authored
      This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,
      
        let x = 1;
        function f(g = () => x) {
          var y
          eval("var x = 2")
          return g() + x  // f() = 3
        }
      
      we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:
      
      - Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.
      
      - When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).
      
      - While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.
      
      - Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.
      
      - Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.
      
      - In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.
      
      - In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.
      
      - ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.
      
      - Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.
      
      - While at it, refactor and unify some respective code in the debugger.
      
      Sorry, this CL is large. I could try to split it up, but everything is rather entangled.
      
      @mstarzinger: Please review the changes to contexts.
      @yangguo: Please have a look at the debugger stuff.
      
      R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
      BUG=v8:811,v8:2160
      LOG=N
      
      Review URL: https://codereview.chromium.org/1292753007
      
      Cr-Commit-Position: refs/heads/master@{#30295}
      365fd7bc
    • rossberg's avatar
      [simd] Introduce SIMD types (as classes) · a60f1922
      rossberg authored
      - Introduce a proper bit for SIMD primitive values.
      - Introduce constructors for individual SIMD types. These are currently just classes, which seems good enough for now, given that we always have exactly one global map per SIMD type.
      
      The only problem with using class types for SIMD is that a SIMD constant won't be a subtype of its specific type, only of the general SIMD type. But until we actually introduce SIMD constants into the compiler that shouldn't matter.
      
      R=jarin@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1303863002
      
      Cr-Commit-Position: refs/heads/master@{#30294}
      a60f1922
    • chunyang.dai's avatar
      X87: [turbofan] Fix stack->stack double moves for pushing on ia32 and x64. · 0afbd7ad
      chunyang.dai authored
      port d0bacc61 (r30235).
      
      original commit message:
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1286123008
      
      Cr-Commit-Position: refs/heads/master@{#30293}
      0afbd7ad
    • chunyang.dai's avatar
      X87: [turbofan] Unify referencing of stack slots · 97a48c53
      chunyang.dai authored
      port cbbaf9ea (r30224).
      
      original commit message:
      
          [turbofan] Unify referencing of stack slots
      
          Previously, it was not possible to specify StackSlotOperands for all
          slots in both the caller and callee stacks. Specifically, the region
          of the callee's stack including the saved return address, frame
          pointer, function pointer and context pointer could not be addressed
          by the register allocator/gap resolver.
      
          In preparation for better tail call support, which will use the gap
          resolver to reconcile outgoing parameters, this change makes it
          possible to address all slots on the stack, because slots in the
          previously inaccessible dead zone may become parameter slots for
          outgoing tail calls. All caller stack slots are accessible as they
          were before, with slot -1 corresponding to the last stack
          parameter. Stack slot indices >= 0 access the callee stack, with slot
          0 corresponding to the callee's saved return address, 1 corresponding
          to the saved frame pointer, 2 corresponding to the current function
          context, 3 corresponding to the frame marker/JSFunction, and slots 4
          and above corresponding to spill slots.
      
          The following changes were specifically     needed:
      
          * Frame     has been changed to explicitly manage three areas of the
            callee frame, the fixed header, the spill slot area, and the
            callee-saved register area.
          * Conversions from stack slot indices to fp offsets all now go through
            a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
          * The generation of deoptimization translation tables has been changed
            to support the new stack slot indexing scheme. Crankshaft, which
            doesn't support the new slot numbering in its register allocator,
            must adapt the indexes when creating translation tables.
          * Callee-saved parameters are now kept below spill slots, not above,
            to support saving only the optimal set of used registers, which is
            only known after register allocation is finished and spill slots
            have been allocated.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1293103003
      
      Cr-Commit-Position: refs/heads/master@{#30292}
      97a48c53
    • mstarzinger's avatar
      Remove code.h header and move ParameterCount class. · 8c70c205
      mstarzinger authored
      R=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1302293002
      
      Cr-Commit-Position: refs/heads/master@{#30291}
      8c70c205
    • chunyang.dai's avatar
      X87: [turbofan] Support unboxed float and double stack parameters and add tests. · ab675145
      chunyang.dai authored
      port 0492bb32 (r30203).
      
      original commit message:
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1306833002
      
      Cr-Commit-Position: refs/heads/master@{#30290}
      ab675145
    • chunyang.dai's avatar
      X87: [interpreter]: Changes to interpreter builtins for accumulator and register file registers. · 8116f95c
      chunyang.dai authored
      port 00df60d1 (r30219).
      
      original commit message:
      
          Makes the following modifications to the interpreter builtins and
          InterpreterAssembler:
           - Adds an accumulator register and initializes it to undefined()
           - Adds a register file pointer register and use it instead of FramePointer to
             access registers
           - Modifies builtin to support functions with 0 regiters in the register file
           - Modifies builtin to Call rather than TailCall to first bytecode handler.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1304593002
      
      Cr-Commit-Position: refs/heads/master@{#30289}
      8116f95c
    • chunyang.dai's avatar
      X87: [simd.js] Single SIMD128_VALUE_TYPE for all Simd128Values. · 682365d7
      chunyang.dai authored
      port f4c079d4 (r30107).
      
      This is the appendix of 458dfe3b943edb3238917edfe9e2dde326cd1adb which misses
      one modified file.
      
      original commit message:
      
          There's no need to have one InstanceType per SIMD primitive type (this
          will not scale long-term).  Also reduce the amount of code duplication
          and make it more robust wrt adding new SIMD types.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1304963003
      
      Cr-Commit-Position: refs/heads/master@{#30288}
      682365d7
    • mlippautz's avatar
      [heap] Thread through GC flags in memory reducer and incremental marking. · 7a21a70c
      mlippautz authored
      BUG=chromium:520607
      LOG=N
      
      Review URL: https://codereview.chromium.org/1302273002
      
      Cr-Commit-Position: refs/heads/master@{#30287}
      7a21a70c
    • wingo's avatar
      Fix parsing of arrow function formal parameters · bb43d6c0
      wingo authored
      Not all parenthesized AssignmentExpressions whose components are valid
      binding patterns are valid arrow function formal parameters.  In
      particular (a,b,c)() is not valid, and in general the existing code
      wasn't catching the tail productions of ConditionalExpression,
      BinaryExpression, PostfixExpression, LeftHandSideExpression,
      and MemberExpression.
      
      Thanks to Adrian Perez for the test case.
      
      BUG=v8:4211
      LOG=Y
      R=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1306583002
      
      Cr-Commit-Position: refs/heads/master@{#30286}
      bb43d6c0
    • yangguo's avatar
      Do not use js builtins object to determine whether a function is a builtin. · 371ad73a
      yangguo authored
      We can use the script type to determine that instead. Script of type
      TYPE_NATIVE are considered builtins, TYPE_NORMAL are not. The only exception
      to this rule is the empty function, for which the script is TYPE_NATIVE
      (observable by the debugger), but should be stringified to "function () {}"
      instead of "function () { [native code] }". For this, I introduce a
      hide_source flag on the script object.
      
      We also use IsBuiltin and IsSubjectToDebugging interchangeably. For debugger,
      we now use the latter, hiding the detail that only non-builtins are debuggable.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1292283004
      
      Cr-Commit-Position: refs/heads/master@{#30285}
      371ad73a
    • mvstanton's avatar
      VectorICs: New interface descriptor for vector transitioning stores. · cd351559
      mvstanton authored
      BUG=
      
      Review URL: https://codereview.chromium.org/1292173003
      
      Cr-Commit-Position: refs/heads/master@{#30284}
      cd351559
    • yangguo's avatar
      Introduce SharedFunctionInfo::Iterator and Script::Iterator. · 4c5efa99
      yangguo authored
      R=mvstanton@chromium.org
      
      Review URL: https://codereview.chromium.org/1300333003
      
      Cr-Commit-Position: refs/heads/master@{#30283}
      4c5efa99
    • mstarzinger's avatar
      Remove obsolete static methods from V8 class. · 01579c6e
      mstarzinger authored
      R=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1303873002
      
      Cr-Commit-Position: refs/heads/master@{#30282}
      01579c6e
    • mlippautz's avatar
      [heap] Cleanup and fix GC flags · a56f5373
      mlippautz authored
      GC flags are now part of the {Heap} and should be respected by all
      sub-components.
      
      Also add a infrastructure to write tests accessing private methods.
      
      Review URL: https://codereview.chromium.org/1301183002
      
      Cr-Commit-Position: refs/heads/master@{#30281}
      a56f5373
    • yangguo's avatar
      Unify symbols sharing across native scripts and runtime. · eaba98d9
      yangguo authored
      We currently have several ways to share symbols that are used in
      both native scripts and the runtime. This change unifies this.
      We do not use the symbols registry since we don't need the
      registry any longer after bootstrapping, but the registry stays
      alive afterwards.
      
      R=mlippautz@chromium.org, rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1293493004
      
      Cr-Commit-Position: refs/heads/master@{#30280}
      eaba98d9
    • v8-autoroll's avatar
      Update V8 DEPS. · 2e84d142
      v8-autoroll authored
      Rolling v8/tools/clang to 5439585778385813bc7711f3d6b7035b9eb78572
      
      TBR=machenbach@chromium.org
      
      Review URL: https://codereview.chromium.org/1307783002
      
      Cr-Commit-Position: refs/heads/master@{#30279}
      2e84d142
  2. 20 Aug, 2015 19 commits
  3. 19 Aug, 2015 2 commits