1. 30 Sep, 2015 1 commit
  2. 30 Sep, 2014 1 commit
  3. 15 Sep, 2014 1 commit
  4. 25 Aug, 2014 1 commit
  5. 05 Aug, 2014 1 commit
  6. 04 Aug, 2014 1 commit
  7. 07 Jul, 2014 1 commit
  8. 03 Jun, 2014 1 commit
  9. 29 Apr, 2014 1 commit
  10. 12 Mar, 2014 1 commit
  11. 07 Nov, 2013 1 commit
  12. 03 Jun, 2013 1 commit
  13. 11 Jun, 2012 1 commit
  14. 04 Jun, 2012 1 commit
  15. 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
  16. 06 May, 2011 1 commit
  17. 22 Mar, 2011 1 commit
  18. 18 Mar, 2011 3 commits
  19. 08 Mar, 2011 1 commit
  20. 04 Feb, 2011 1 commit
  21. 02 Feb, 2011 1 commit
    • kmillikin@chromium.org's avatar
      Partial fix for V8 issue 1079. · f1149734
      kmillikin@chromium.org authored
      Record a safepoint with a deoptimization id for throw in optimized code.  We
      don't seem to much care what the AST ID is because we will not be using it
      for lazy deoptimization (throw doesn't return to the point of throw).  For
      hygiene we use the actual ID of the throw expression.  Throw is no longer a
      control-flow instruction, but it's followed by an unconditional abnormal
      exit.  This is required to insert a simulate between the throw and the exit.
      
      Make our optimized treatment of Function.prototype.apply act like a call and
      have side effects.  This ensures that it will get a lazy deoptimization
      environment.  Use that deoptimization ID in the safepoint for the call.
      
      Deleting a property was also missing a deoptimization ID, though there was a
      deoptimization environment assigned to the instruction.  Record the
      environment and use the deoptimization ID at the safepoint.
      
      Review URL: http://codereview.chromium.org/6250105
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6576 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f1149734
  22. 26 Jan, 2011 1 commit
  23. 14 Jan, 2011 1 commit
  24. 12 Jan, 2011 1 commit
  25. 10 Jan, 2011 3 commits
  26. 07 Dec, 2010 3 commits