Skip to content

V
V8
Switch branch/tag
  1. 06 Mar, 2012 1 commit
  3. 28 Feb, 2012 1 commit
  5. 13 Jan, 2012 1 commit
  7. 11 Jan, 2012 1 commit
  9. 10 Jan, 2012 1 commit
  11. 09 Jan, 2012 1 commit
  13. 04 Jan, 2012 2 commits
  15. 23 Dec, 2011 1 commit
  17. 25 Nov, 2011 1 commit
  19. 24 Nov, 2011 2 commits
    • 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
    • mstarzinger@chromium.org's avatar
      Implement crankshaft support for nested object literals. · 7e7d4dfd
      mstarzinger@chromium.org authored 
      This generates optimized code for deep-copying of nested object literal
boilerplates which are statically known. Most of the boilerplates have
already been generated at crankshaft time, so this optimization should
kick in for virtually every object literal. Only nested object literal
graphs up to a certain depth and containing up to a certain total number
of properties are considered for this optimization. This will prevent
explosion of code size due to large object literals (e.g. eval on JSON).
Improves splay performance because object literals are created often.

R=fschneider@chromium.org

Review URL: http://codereview.chromium.org/8640001

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      7e7d4dfd
  21. 17 Nov, 2011 1 commit
  23. 16 Nov, 2011 1 commit
    • fschneider@chromium.org's avatar
      Fix lazy deoptimization at HInvokeFunction and enable target-recording call-function stub. · 84805694
      fschneider@chromium.org authored 
      Changes the way we do lazy deoptimization:

1. For side-effect instructions, we insert the lazy-deopt call at
the following LLazyBailout instruction.

     CALL
     GAP
     LAZY-BAILOUT ==> lazy-deopt-call

2. For other instructions (StackCheck) we insert it right after the
instruction since the deopt targets an earlier deoptimization environment.

   STACK-CHECK
   GAP ==> lazy-deopt-call

The pc of the lazy-deopt call that will be patched in is recorded in the
deoptimization input data. Each Lithium instruction can have 0..n safepoints.
All safepoints get the deoptimization index of the associated LAZY-BAILOUT
instruction. On lazy deoptimization we use the return-pc to find the safepoint.
The safepoint tells us the deoptimization index, which in turn finds us the
PC where to insert the lazy-deopt-call.

Additional changes:
 * RegExpLiteral marked it as having side-effects so that it 
   gets an explicitlazy-bailout instruction (instead of
   treating it specially like stack-checks)
 * Enable target recording CallFunctionStub to achieve
   more inlining on optimized code.

BUG=v8:1789
TEST=jslint and uglify run without crashing, mjsunit/compiler/regress-lazy-deopt.js
Review URL: http://codereview.chromium.org/8492004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      84805694
  25. 08 Nov, 2011 2 commits
  27. 24 Oct, 2011 1 commit
  29. 20 Oct, 2011 1 commit
  31. 18 Oct, 2011 1 commit
  33. 14 Oct, 2011 1 commit
  35. 26 Sep, 2011 1 commit
  37. 29 Jun, 2011 1 commit
  39. 28 Jun, 2011 1 commit
  41. 27 Jun, 2011 1 commit
  43. 23 Jun, 2011 1 commit
  45. 22 Jun, 2011 1 commit
  47. 09 Jun, 2011 1 commit
  49. 24 May, 2011 1 commit
    • ager@chromium.org's avatar
      Fix calls of strict mode function with an implicit receiver. · 6f775f2f
      ager@chromium.org authored 
      Only IA32 version for now. I'll start porting.

Strict mode functions are to get 'undefined' as the receiver when
called with an implicit receiver. Modes are bad! It forces us to have
checks on all function calls.

This change attempts to limit the cost by passing information about
whether or not a call is with an implicit or explicit receiver in ecx
as part of the calling convention. The cost is setting ecx on all
calls and checking ecx on entry to strict mode functions.

Implicit/explicit receiver state has to be maintained by ICs. Various
stubs have to not clobber ecx or save and restore it.

CallFunction stub needs to check if the receiver is implicit when it
doesn't know from the context.

Review URL: http://codereview.chromium.org/7039036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8040 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      6f775f2f
  51. 23 May, 2011 1 commit
  53. 17 May, 2011 2 commits
  55. 05 May, 2011 1 commit
  57. 27 Apr, 2011 1 commit
  59. 15 Apr, 2011 1 commit
  61. 07 Apr, 2011 1 commit
  63. 06 Apr, 2011 1 commit
  65. 24 Mar, 2011 1 commit
  67. 18 Mar, 2011 3 commits