1. 02 May, 2019 1 commit
  2. 28 Apr, 2017 1 commit
  3. 26 Jan, 2017 3 commits
  4. 19 Oct, 2015 1 commit
  5. 16 Oct, 2015 2 commits
    • jarin's avatar
      Revert of [turbofan] Initial support for monomorphic/polymorphic property... · 5c534812
      jarin authored
      Revert of [turbofan] Initial support for monomorphic/polymorphic property loads. (patchset #3 id:100001 of https://codereview.chromium.org/1396333010/ )
      
      Reason for revert:
      Waterfall redness.
      
      Original issue's description:
      > [turbofan] Initial support for monomorphic/polymorphic property loads.
      >
      > Native context specialization now lowers monomorphic and
      > polymorphic accesses to data and constant data properties on
      > object and/or prototype chain. We don't deal with accessors
      > yet, and we also completely ignore proxies (which is compatible
      > with what Crankshaft does).
      >
      > The code is more or less the straightforward implementation. We
      > will need to refactor that and extract common patterns once the
      > remaining bits for full load/store support is in.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
      > R=jarin@chromium.org
      > BUG=v8:4470
      > LOG=n
      >
      > Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e
      > Cr-Commit-Position: refs/heads/master@{#31340}
      
      TBR=bmeurer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4470
      
      Review URL: https://codereview.chromium.org/1408123002
      
      Cr-Commit-Position: refs/heads/master@{#31341}
      5c534812
    • bmeurer's avatar
      [turbofan] Initial support for monomorphic/polymorphic property loads. · 3a0bf860
      bmeurer authored
      Native context specialization now lowers monomorphic and
      polymorphic accesses to data and constant data properties on
      object and/or prototype chain. We don't deal with accessors
      yet, and we also completely ignore proxies (which is compatible
      with what Crankshaft does).
      
      The code is more or less the straightforward implementation. We
      will need to refactor that and extract common patterns once the
      remaining bits for full load/store support is in.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
      R=jarin@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1396333010
      
      Cr-Commit-Position: refs/heads/master@{#31340}
      3a0bf860
  6. 12 Aug, 2015 1 commit
  7. 13 Mar, 2015 1 commit
  8. 25 Feb, 2015 1 commit
  9. 05 Jun, 2014 1 commit
  10. 24 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Introduce extended mode. · 1e9a7267
      keuchel@chromium.org authored
      This CL introduces a third mode next to the non-strict
      (henceforth called 'classic mode') and 'strict mode'
      which is called 'extended mode' as in the current
      ES.next specification drafts. The extended mode is based on
      the 'strict mode' and adds new functionality to it. This
      means that most of the semantics of these two modes
      coincide.
      
      The 'extended mode' is entered instead of the 'strict mode'
      during parsing when using the 'strict mode' directive
      "use strict" and when the the harmony-scoping flag is
      active. This should be changed once it is fully specified how the 'extended mode' is entered.
      
      This change introduces a new 3 valued enum LanguageMode
      (see globals.h) corresponding to the modes which is mostly
      used by the frontend code. This includes the following
      components:
      * (Pre)Parser
      * Compiler
      * SharedFunctionInfo, Scope and ScopeInfo
      * runtime functions: StoreContextSlot,
        ResolvePossiblyDirectEval, InitializeVarGlobal,
        DeclareGlobals
      
      The old enum StrictModeFlag is still used in the backend
      when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
      * SetProperty runtime function, Delete builtin
      * StoreIC and KeyedStoreIC
      * StubCache
      
      Review URL: http://codereview.chromium.org/8417035
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1e9a7267
  11. 25 Oct, 2011 1 commit
  12. 12 Oct, 2011 1 commit
  13. 16 Aug, 2011 1 commit
  14. 11 Aug, 2011 1 commit
  15. 28 Jul, 2011 1 commit
  16. 01 Jul, 2011 1 commit
  17. 11 Apr, 2011 1 commit
  18. 07 Mar, 2011 1 commit
  19. 17 Feb, 2011 1 commit
  20. 20 Jan, 2011 1 commit
  21. 05 Jan, 2011 1 commit
  22. 23 Oct, 2009 1 commit
  23. 20 Oct, 2009 1 commit
  24. 04 Mar, 2009 1 commit
  25. 26 Sep, 2008 1 commit
  26. 09 Sep, 2008 1 commit
  27. 22 Aug, 2008 1 commit
    • christian.plesner.hansen's avatar
      Included mjsunit JavaScript test suite and C++ unit tests. · c42f5829
      christian.plesner.hansen authored
      In the shell sample don't print the result of executing a script, only
      evaluating expressions.
      
      Fixed issue when building samples on Windows using a shared V8
      library.  Added visibility option on Linux build which makes the
      generated library 18% smaller.
      
      Changed build system to accept multiple build modes in one build and
      generate seperate objects, libraries and executables for each mode.
      
      Removed deferred negation optimization (a * -b => -(a * b)) since this
      visibly changes operand conversion order.
      
      Improved parsing performance by introducing stack guard in preparsing.
      Without a stack guard preparsing always bails out with stack overflow.
      
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c42f5829
  28. 03 Jul, 2008 1 commit