1. 17 May, 2016 2 commits
  2. 13 May, 2016 1 commit
  3. 11 May, 2016 2 commits
  4. 10 May, 2016 1 commit
  5. 06 May, 2016 2 commits
  6. 04 May, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Remove dangerous language mode accessors. · db1b27e8
      mstarzinger authored
      The language mode is no longer constant accross a compilation unit. For
      example the extends clause of a class literal can be in strict mode even
      though the surrounding function is in sloppy mode. This makes any global
      language mode predicate that reasons over an entire function inherently
      dangerous. Instead one should use the appropriate predicate on scopes or
      literals directly.
      
      R=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/1949013002
      Cr-Commit-Position: refs/heads/master@{#36010}
      db1b27e8
  7. 26 Apr, 2016 1 commit
  8. 07 Apr, 2016 1 commit
  9. 01 Apr, 2016 1 commit
  10. 30 Mar, 2016 1 commit
  11. 29 Mar, 2016 1 commit
    • bmeurer's avatar
      [crankshaft] Address the deoptimization loops of Math.floor, Math.round and Math.ceil. · 978ad03b
      bmeurer authored
      Fix and re-enable the flexible representation for Math.floor (which is used to
      implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
      return double results instead of int32, and therefore allows values outside
      the int32 range, especially -0 is now a valid result, which doesn't deopt.
      
      Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
      extension.
      
      This addresses all the known deoptimization loops related to Math.round
      in the Kraken benchmark suite, and seems to also address most of the
      deoptimization loops related to Math.floor in the Oort Online benchmark.
      
      Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
      optimization that caused the initial revert of the feature (for arm64 only
      back then).
      
      BUG=chromium:476477,v8:2890,v8:4059
      R=jarin@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1841513003
      
      Cr-Commit-Position: refs/heads/master@{#35094}
      978ad03b
  12. 22 Mar, 2016 3 commits
  13. 21 Mar, 2016 2 commits
  14. 16 Mar, 2016 3 commits
  15. 09 Mar, 2016 1 commit
  16. 08 Mar, 2016 2 commits
    • verwaest's avatar
      Don't do any special normalization if a boilerplate contains function literals. · fd405704
      verwaest authored
      This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
      
      function.prototype = {
        method: function() { ... }
      }
      
      Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
      
      This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
      
      BUG=chromium:593008
      LOG=n
      
      Review URL: https://codereview.chromium.org/1772423002
      
      Cr-Commit-Position: refs/heads/master@{#34602}
      fd405704
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored
      Before this CL, various code stubs used different techniques
      for marking their frames to enable stack-crawling and other
      access to data in the frame. All of them were based on a abuse
      of the "standard" frame representation, e.g. storing the a
      context pointer immediately below the frame's fp, and a
      function pointer after that. Although functional, this approach
      tends to make stubs and builtins do an awkward, unnecessary
      dance to appear like standard frames, even if they have
      nothing to do with JavaScript execution.
      
      This CL attempts to improve this by:
      
      * Ensuring that there are only two fundamentally different
        types of frames, a "standard" frame and a "typed" frame.
        Standard frames, as before, contain both a context and
        function pointer. Typed frames contain only a minimum
        of a smi marker in the position immediately below the fp
        where the context is in standard frames.
      * Only interpreted, full codegen, and optimized Crankshaft and
        TurboFan JavaScript frames use the "standard" format. All
        other frames use the type frame format with an explicit
        marker.
      * Typed frames can contain one or more values below the
        type marker. There is new magic macro machinery in
        frames.h that simplifies defining the offsets of these fields
        in typed frames.
      * A new flag in the CallDescriptor enables specifying whether
        a frame is a standard frame or a typed frame. Secondary
        register location spilling is now only enabled for standard
        frames.
      * A zillion places in the code have been updated to deal with
        the fact that most code stubs and internal frames use the
        typed frame format. This includes changes in the
        deoptimizer, debugger, and liveedit.
      * StandardFrameConstants::kMarkerOffset is deprecated,
        (CommonFrameConstants::kContextOrFrameTypeOffset
        and StandardFrameConstants::kFrameOffset are now used
        in its stead).
      
      LOG=N
      
      Review URL: https://codereview.chromium.org/1696043002
      
      Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  17. 07 Mar, 2016 1 commit
    • ishell's avatar
      [crankshaft] Support ES6 tail call elimination. · 22938040
      ishell authored
      HInvokeFunction and HApplyArguments instructions now support tail calling.
      
      Inlining of calls at tail position is not supported yet and therefore still disabled.
      
      The tail-call-megatest was modified so that the usages of "arguments" object do not disable Crankshaft.
      
      TBR=bmeurer@chromium.org
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1760253003
      
      Cr-Commit-Position: refs/heads/master@{#34542}
      22938040
  18. 04 Mar, 2016 1 commit
    • bmeurer's avatar
      [compiler] Introduce code stubs for string relational comparisons. · 5912e0f0
      bmeurer authored
      Add StringLessThanStub, StringLessThanOrEqualStub, StringGreaterThanStub
      and StringGreaterThanOrEqualStub, based on the CodeStubAssembler, and
      hook them up with TurboFan (and Ignition). The stubs are currently
      essentially comparable with the StringCompareStub, which is now
      obsolete. We can later extend these stubs to cover more interesting
      cases (i.e. two byte sequential string comparisons, etc.).
      
      R=epertoso@chromium.org
      
      Review URL: https://codereview.chromium.org/1765823002
      
      Cr-Commit-Position: refs/heads/master@{#34485}
      5912e0f0
  19. 03 Mar, 2016 1 commit
    • bmeurer's avatar
      [compiler] Introduce StringEqualStub and StringNotEqualStub. · 2689548e
      bmeurer authored
      These new stubs perform exactly the same job as the string equality case
      for the CompareIC, but are platform independent and usable outside of
      fullcodegen and Crankshaft. We use them in the StrictEqualStub and the
      StrictNotEqualStub instead of falling back to the runtime immediately
      for String comparisons, and we also use them in TurboFan to perform
      String equality or inequality comparisons.
      
      These stubs currently handle only internalized and one byte strings w/o
      going to C++, but it should be easy to add support for more string cases
      later, i.e. utilizing already flattened cons strings or comparing two
      byte strings as well.
      
      Review URL: https://codereview.chromium.org/1761823002
      
      Cr-Commit-Position: refs/heads/master@{#34459}
      2689548e
  20. 29 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a proper ToBooleanStub. · d1df58e8
      bmeurer authored
      Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
      our naming convention, and add a new TurboFan-powered ToBooleanStub,
      which just does the ToBoolean conversion without any runtime call or
      code patching, so we can use it for Ignition (and TurboFan).
      
      Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
      already have for to_string and to_number, so we don't need to actually
      dispatch on the concrete Oddball at all.
      
      R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1744163002
      
      Cr-Commit-Position: refs/heads/master@{#34361}
      d1df58e8
  21. 26 Feb, 2016 1 commit
  22. 24 Feb, 2016 1 commit
  23. 18 Feb, 2016 1 commit
  24. 17 Feb, 2016 5 commits
  25. 16 Feb, 2016 1 commit
  26. 11 Feb, 2016 1 commit
  27. 10 Feb, 2016 1 commit
    • verwaest's avatar
      Mark null and undefined as undetectable, and use it to handle abstract... · 3ce9e808
      verwaest authored
      Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic
      
      Marking as undetectable makes abstract equality of null, undefined, and
      other undetectable objects easier. Supporting it in the generic compare
      IC significantly speeds up dynamic comparison between those values and
      JSReceivers by not falling back to the runtime.
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>
      
      Review URL: https://codereview.chromium.org/1683643002
      
      Cr-Commit-Position: refs/heads/master@{#33858}
      3ce9e808