1. 13 Oct, 2017 1 commit
  2. 06 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [assembler] Make Register et al. real classes · 9e995e12
      Clemens Hammacher authored
      Up to now, each architecture defined all Register types as structs,
      with lots of redundancy. An often found comment noted that they cannot
      be classes due to initialization order problems. As these problems are
      gone with C++11 constexpr constants, I now tried making Registers
      classes again.
      All register types now inherit from RegisterBase, which provides a
      default set of methods and named constructors (like ::from_code,
      code(), bit(), is_valid(), ...).
      This design allows to guarantee an interesting property: Each register
      is either valid, or it's the no_reg register. There are no other
      invalid registers. This is guaranteed statically by the constexpr
      constructor, and dynamically by ::from_code.
      
      I decided to disallow the default constructor completely, so instead of
      "Register reg;" you now need "Register reg = no_reg;". This makes
      explicit how the Register is initialized.
      
      I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
      Overall, code got much more compact and more safe. In theory, it should
      also increase performance (since the is_valid() check is simpler), but
      this is probably not measurable.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
      Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47847}
      9e995e12
  3. 22 Aug, 2017 1 commit
  4. 02 Aug, 2017 1 commit
  5. 01 Aug, 2017 2 commits
  6. 23 May, 2017 1 commit
    • Clemens Hammacher's avatar
      Avoid emitting redundant safepoint info · df1cb4e8
      Clemens Hammacher authored
      Before emitting the safepoint table, remove consecutive identical
      entries (idential except for the pc of course). The lookup then
      searches for the last entry whose pc is <= the wanted pc.
      The lookup procedure can still be optimized to use binary search
      laster.
      
      This change decreases code size for wasm by 27.6% (on the unity
      benchmark).
      
      BUG=v8:6434
      
      Change-Id: I03481721fe666cd2c50a383380c74b06edf39106
      Reviewed-on: https://chromium-review.googlesource.com/512542
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45491}
      df1cb4e8
  7. 12 Apr, 2017 1 commit
  8. 20 Sep, 2016 1 commit
  9. 30 Sep, 2015 1 commit
  10. 30 Sep, 2014 1 commit
  11. 15 Sep, 2014 1 commit
  12. 25 Aug, 2014 1 commit
  13. 05 Aug, 2014 1 commit
  14. 04 Aug, 2014 1 commit
  15. 07 Jul, 2014 1 commit
  16. 03 Jun, 2014 1 commit
  17. 29 Apr, 2014 1 commit
  18. 12 Mar, 2014 1 commit
  19. 07 Nov, 2013 1 commit
  20. 03 Jun, 2013 1 commit
  21. 11 Jun, 2012 1 commit
  22. 04 Jun, 2012 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
  24. 06 May, 2011 1 commit
  25. 22 Mar, 2011 1 commit
  26. 18 Mar, 2011 3 commits
  27. 08 Mar, 2011 1 commit
  28. 04 Feb, 2011 1 commit
  29. 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
  30. 26 Jan, 2011 1 commit
  31. 14 Jan, 2011 1 commit
  32. 12 Jan, 2011 1 commit
  33. 10 Jan, 2011 3 commits
  34. 07 Dec, 2010 2 commits