1. 22 Oct, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter] Fill out function prologue support. · 6256e1dc
      rmcilroy authored
      Fills out some more of the function prologue support in the
      interpreter. Deals with creation of arguments objects and throwing
      IllegalRedeclarations if necessary. Also adds (untested) support for
      this.function and new.target variable assignment.
      
      Also fixes a bug in Frames::is_java_script() to deal with
      interpreter frames correctly.
      
      Cleans up comments in builtins InterpreterEntryTrampoline about
      missing prologue support.
      
      Adds the following bytecodes:
        - CreateArgumentsSloppy
        - CreateArgumentsStrict
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1412953007
      
      Cr-Commit-Position: refs/heads/master@{#31486}
      6256e1dc
  2. 15 Oct, 2015 3 commits
  3. 06 Oct, 2015 1 commit
  4. 02 Oct, 2015 5 commits
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · 75f6ad74
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31089}
      75f6ad74
    • rmcilroy's avatar
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset... · b4a2f656
      rmcilroy authored
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #8 id:220001 of https://codereview.chromium.org/1362383002/ )
      
      Reason for revert:
      Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot)
      
      Original issue's description:
      > [Interpreter] Add CallRuntime support to the interpreter.
      >
      > Adds support for calling runtime functions from the interpreter. Adds the
      > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      > and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      > to enable the interpreter to enter C++ code based on the functionId.
      >
      > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      > and groups all the interpreter builtins together.
      >
      > BUG=v8:4280
      > LOG=N
      >
      
      TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review URL: https://codereview.chromium.org/1379933003
      
      Cr-Commit-Position: refs/heads/master@{#31078}
      b4a2f656
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · c991d8f3
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
      Cr-Commit-Position: refs/heads/master@{#31064}
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31076}
      c991d8f3
    • rmcilroy's avatar
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset... · 90f69d16
      rmcilroy authored
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #6 id:180001 of https://codereview.chromium.org/1362383002/ )
      
      Reason for revert:
      Broke Arm64 bot (CEntry stub is trying to pop arguments off stack when argv_in_reg, so I need to fix this).
      
      Original issue's description:
      > [Interpreter] Add CallRuntime support to the interpreter.
      >
      > Adds support for calling runtime functions from the interpreter. Adds the
      > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      > and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      > to enable the interpreter to enter C++ code based on the functionId.
      >
      > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      > and groups all the interpreter builtins together.
      >
      > BUG=v8:4280
      > LOG=N
      >
      > Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
      > Cr-Commit-Position: refs/heads/master@{#31064}
      
      TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review URL: https://codereview.chromium.org/1387543002
      
      Cr-Commit-Position: refs/heads/master@{#31066}
      90f69d16
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · 40e8424b
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31064}
      40e8424b
  5. 24 Sep, 2015 3 commits
    • 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
  6. 23 Sep, 2015 2 commits
    • bmeurer's avatar
      [runtime] Remove weird pushing of something on StackOverflow. · 556b522a
      bmeurer authored
      We somehow try to push some stuff on the stack when we detect a stack
      overflow, that we don't need. Even worse we might access outside the
      valid stack bounds. Since we don't need this, it's gone.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      R=jarin@chromium.org
      BUG=chromium:534881
      LOG=n
      
      Review URL: https://codereview.chromium.org/1360953003
      
      Cr-Commit-Position: refs/heads/master@{#30883}
      556b522a
    • bmeurer's avatar
      [builtin] Refactor Invoke to deal with any kind of callable. · 634d1d86
      bmeurer authored
      Now both Execution::Call and Execution::New can deal with any
      kind of target and will raise a proper exception if the target is not
      callable (which is not yet spec compliant for New, as we would
      have to check IsConstructor instead, which we don't have yet).
      
      Now we no longer need to do any of these weird call/construct
      delegate gymnastics in C++, and we finally have a single true
      bottleneck for Call/Construct abstract operations in the code
      base, with only a few special handlings left in the compilers to
      optimize the JSFunction case.
      
      R=jarin@chromium.org
      BUG=v8:4430, v8:4413
      LOG=n
      
      Review URL: https://codereview.chromium.org/1360793002
      
      Cr-Commit-Position: refs/heads/master@{#30874}
      634d1d86
  7. 22 Sep, 2015 1 commit
    • bmeurer's avatar
      [builtins] Add support for NewTarget to Execution::New. · 1dfac69f
      bmeurer authored
      Introduce new builtins Construct and ConstructFunction (in line
      with the Call and CallFunction builtins that we already have) as
      proper bottleneck for Construct and [[Construct]] on JSFunctions.
      Use these builtins to support passing NewTarget from C++ to
      JavaScript land.
      
      Long-term we want the CallConstructStub to be used for
      gathering feedback on entry to construction chain (i.e. the
      initial new Foo), and use the Construct builtins to do the
      actual work inside the construction chain (i.e. calling into
      super and stuff).
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=jarin@chromium.org
      BUG=v8:4430
      LOG=n
      
      Review URL: https://codereview.chromium.org/1359583002
      
      Cr-Commit-Position: refs/heads/master@{#30857}
      1dfac69f
  8. 17 Sep, 2015 3 commits
  9. 16 Sep, 2015 3 commits
    • mvstanton's avatar
      Remove --pretenure-call-new · b5588f48
      mvstanton authored
      There isn't a plan to turn it on soon, so we'll take it out in favor of cleaner code.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1202173002
      
      Cr-Commit-Position: refs/heads/master@{#30767}
      b5588f48
    • bmeurer's avatar
      [builtins] Unify the String constructor. · a3d6f6cc
      bmeurer authored
      Implement the String constructor completely as native builtin,
      avoiding the need to do gymnastics in JavaScript builtin to
      properly detect the no argument case (which is different from
      the undefined argument case) and also allowing to just
      tailcall through to ToString or SymbolDescriptiveString for
      the common case. Also the JavaScript builtin was misleading
      since the case for construct call was unused, but could be
      triggered in a wrong way once we support tail calls from
      constructor functions.
      
      This refactoring allows us to properly implement subclassing
      for String builtins, once we have the correct initial_map on
      derived classes (it's merely a matter of using NewTarget
      instead of the target register now).
      
      This introduces a new %SymbolDescriptiveString runtime
      entry, which is also used by Symbol.toString() now.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1344893002
      
      Cr-Commit-Position: refs/heads/master@{#30759}
      a3d6f6cc
    • mvstanton's avatar
      Vector ICs: Hook up vectors in platform builtins to their SharedFunctionInfos. · 905e008c
      mvstanton authored
      BUG=v8:4423
      LOG=N
      
      Review URL: https://codereview.chromium.org/1342013003
      
      Cr-Commit-Position: refs/heads/master@{#30758}
      905e008c
  10. 14 Sep, 2015 2 commits
    • rmcilroy's avatar
      [Interpreter] Add support for JS calls. · e7fb2339
      rmcilroy authored
      Adds support for JS calls to the interpreter. In order to support
      calls from the interpreter, the PushArgsAndCall builtin is added
      which pushes a sequence of arguments onto the stack and calls
      builtin::Call.
      
      Adds the Call bytecode.
      
      MIPS port contributed by akos.palfi@imgtec.com in https://codereview.chromium.org/1334873002/
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1323463005
      
      Cr-Commit-Position: refs/heads/master@{#30710}
      e7fb2339
    • bmeurer's avatar
      [builtins] Simplify String constructor code. · eadfd666
      bmeurer authored
      The String constructor was somewhat complex with a lot of micro
      optimizations that are not relevant or even misguided. It would be
      really hard to port that code to ES6, which requires String to be
      subclassable. So as a first step we reduced the necessary complexity
      to the bare minimum (also removing the last user of the fairly complex
      MacroAssembler::LookupNumberStringCache method).
      
      This also removes the counters for the String constructor, which
      were not properly exposed anymore (and not kept in sync with inlined
      versions of the String constructor anyway).
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1335193002
      
      Cr-Commit-Position: refs/heads/master@{#30706}
      eadfd666
  11. 11 Sep, 2015 1 commit
  12. 08 Sep, 2015 3 commits
    • bmeurer's avatar
      [builtins] Unify the various versions of [[Call]] with a Call builtin. · ccbb4ff0
      bmeurer authored
      The new Call and CallFunction builtins supersede the current
      CallFunctionStub (and CallIC magic) and will be the single bottleneck
      for all calling, including the currently special Function.prototype.call
      and Function.prototype.apply builtins, which had handwritten (and
      not fully compliant) versions of CallFunctionStub, and also the
      CallIC(s), which where also slightly different.
      
      This also reduces the overhead for API function calls, which is still
      unnecessary high, but let's do that step-by-step.
      
      This also fixes a bunch of cases where the implicit ToObject for
      sloppy receivers was done in the wrong context (in the caller
      context instead of the callee context), which basically meant
      that we allowed cross context access to %ObjectPrototype%.
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      BUG=v8:4413
      LOG=n
      
      Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
      Cr-Commit-Position: refs/heads/master@{#30627}
      
      Review URL: https://codereview.chromium.org/1311013008
      
      Cr-Commit-Position: refs/heads/master@{#30629}
      ccbb4ff0
    • bmeurer's avatar
      Revert of [builtins] Unify the various versions of [[Call]] with a Call... · 298d4a6b
      bmeurer authored
      Revert of [builtins] Unify the various versions of [[Call]] with a Call builtin. (patchset #10 id:260001 of https://codereview.chromium.org/1311013008/ )
      
      Reason for revert:
      Breaks nosnap, needs investigation
      
      Original issue's description:
      > [builtins] Unify the various versions of [[Call]] with a Call builtin.
      >
      > The new Call and CallFunction builtins supersede the current
      > CallFunctionStub (and CallIC magic) and will be the single bottleneck
      > for all calling, including the currently special Function.prototype.call
      > and Function.prototype.apply builtins, which had handwritten (and
      > not fully compliant) versions of CallFunctionStub, and also the
      > CallIC(s), which where also slightly different.
      >
      > This also reduces the overhead for API function calls, which is still
      > unnecessary high, but let's do that step-by-step.
      >
      > This also fixes a bunch of cases where the implicit ToObject for
      > sloppy receivers was done in the wrong context (in the caller
      > context instead of the callee context), which basically meant
      > that we allowed cross context access to %ObjectPrototype%.
      >
      > MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      >
      > R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
      > BUG=v8:4413
      > LOG=n
      >
      > Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
      > Cr-Commit-Position: refs/heads/master@{#30627}
      
      TBR=rmcilroy@chromium.org,jarin@chromium.org,mstarzinger@chromium.org,mvstanton@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4413
      
      Review URL: https://codereview.chromium.org/1328963004
      
      Cr-Commit-Position: refs/heads/master@{#30628}
      298d4a6b
    • bmeurer's avatar
      [builtins] Unify the various versions of [[Call]] with a Call builtin. · ef268a83
      bmeurer authored
      The new Call and CallFunction builtins supersede the current
      CallFunctionStub (and CallIC magic) and will be the single bottleneck
      for all calling, including the currently special Function.prototype.call
      and Function.prototype.apply builtins, which had handwritten (and
      not fully compliant) versions of CallFunctionStub, and also the
      CallIC(s), which where also slightly different.
      
      This also reduces the overhead for API function calls, which is still
      unnecessary high, but let's do that step-by-step.
      
      This also fixes a bunch of cases where the implicit ToObject for
      sloppy receivers was done in the wrong context (in the caller
      context instead of the callee context), which basically meant
      that we allowed cross context access to %ObjectPrototype%.
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
      BUG=v8:4413
      LOG=n
      
      Review URL: https://codereview.chromium.org/1311013008
      
      Cr-Commit-Position: refs/heads/master@{#30627}
      ef268a83
  13. 31 Aug, 2015 1 commit
    • bmeurer's avatar
      [builtins] Pass correct number of arguments after adapting arguments. · fbad6366
      bmeurer authored
      The call protocol requires that the register dedicated to the number of
      actual arguments (i.e. rax on x64) always contains the actual arguments.
      That means after adapting arguments it should match the number of
      expected arguments.  But currently we pass some semi-random value
      (usually some stack address) after adapting arguments.
      
      It looks like this is currently not observable anywhere, because our
      builtins and functions either don't look at the number of arguments and
      just make hard coded (unchecked) assumptions, or are marked as "don't
      adapt arguments", which bypasses the broken code in the trampoline for
      arguments adaption.  Nevertheless this should be fixed.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1306423003
      
      Cr-Commit-Position: refs/heads/master@{#30467}
      fbad6366
  14. 28 Aug, 2015 1 commit
  15. 27 Aug, 2015 2 commits
  16. 18 Aug, 2015 1 commit
  17. 17 Aug, 2015 1 commit
  18. 11 Aug, 2015 1 commit
    • bmeurer's avatar
      [runtime] Store constructor function index on primitive maps. · 6c743b2b
      bmeurer authored
      This way we can greatly simplify the different variants of ToObject in
      our codebase and make them more uniform and robust.  Adding a new
      primitive doesn't require finding and changing all those places again,
      but it is sufficient to setup the constructor function index when
      allocating the map.
      
      We use the inobject properties field of Map, which is invalid primitive
      maps anyway.
      
      R=jkummerow@chromium.org
      
      Review URL: https://codereview.chromium.org/1276533003
      
      Cr-Commit-Position: refs/heads/master@{#30119}
      6c743b2b
  19. 31 Jul, 2015 2 commits
    • mvstanton's avatar
      VectorICs: refactoring to eliminate "for queries only" vector ic mode. · 1a5751f9
      mvstanton authored
      Since we need the notion of a dummy vector ic, we can use that to avoid
      a special case of the IC constructor. Also, consolidate the two dummy
      ICs into one.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1268783004
      
      Cr-Commit-Position: refs/heads/master@{#29956}
      1a5751f9
    • bmeurer's avatar
      [stubs] Unify (and optimize) implementation of ToObject. · 4fc6f547
      bmeurer authored
      This is the initial (big) step towards a more uniform implementation of
      the ToObject abstract operation (ES6 7.1.13), where we have a fallback
      implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
      to deal with the fast case (we should be able to do more cleanup on this
      in a followup CL).  For natives we expose the abstract operation via a
      %_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
      the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
      $toObject and %$toObject.  Now the whole implementation of the abstract
      operation is context independent, meaning we don't need any magic in the
      builtins object nor the native context.
      
      R=mvstanton@chromium.org,yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1266013006
      
      Cr-Commit-Position: refs/heads/master@{#29953}
      4fc6f547
  20. 30 Jul, 2015 1 commit
  21. 24 Jul, 2015 1 commit
  22. 17 Jul, 2015 1 commit