1. 06 Apr, 2016 2 commits
    • verwaest's avatar
      Use a dictionary-mode code cache on the map rather than a dual system. · d2eb555e
      verwaest authored
      The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.
      
      This CL additionally deletes some dead IC code.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1846963002
      
      Cr-Commit-Position: refs/heads/master@{#35291}
      d2eb555e
    • bmeurer's avatar
      [generators] Decouple generator resume from fullcodegen. · 974721c6
      bmeurer authored
      Introduce a ResumeGeneratorTrampoline, which does the actual stack state
      reconstruction (currently always restores a fullcodegen frame), and
      introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
      %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
      this native builtin.
      
      Also unify the flooding in case of step-in to always work based on
      JSFunction and remove the special casing for JSGeneratorObject.
      
      R=mstarzinger@chromium.org, neis@chromium.org
      TBR=rossberg@chromium.org
      BUG=chromium:513471
      LOG=n
      
      Review URL: https://codereview.chromium.org/1865833002
      
      Cr-Commit-Position: refs/heads/master@{#35283}
      974721c6
  2. 04 Apr, 2016 1 commit
  3. 31 Mar, 2016 2 commits
  4. 30 Mar, 2016 3 commits
  5. 29 Mar, 2016 1 commit
  6. 25 Mar, 2016 2 commits
  7. 22 Mar, 2016 3 commits
  8. 21 Mar, 2016 5 commits
  9. 18 Mar, 2016 1 commit
  10. 17 Mar, 2016 1 commit
  11. 16 Mar, 2016 4 commits
  12. 11 Mar, 2016 1 commit
  13. 10 Mar, 2016 3 commits
  14. 09 Mar, 2016 6 commits
    • alan.li's avatar
      MIPS: Fix '[wasm] add rotate opcodes' · 4ec5a1e3
      alan.li authored
      Port 9d0cf920
      
      Bug Descriptions:
      1. We are missing drotr32 instruction
      2. Ror Macro should also handle values less than zero or bigger than 31, as WASM instruction kExprI32Rol will generate shifting operands beyond [0 .. 31] range.
      3. Same as Dror.
      4. drotrv instruction in simulator is incorrect.
      
      BUG=
      TEST=cctest/test-run-wasm/Run_WasmInt32Binops,cctest/test-run-wasm/Run_WasmInt64Binops
      
      Review URL: https://codereview.chromium.org/1776623002
      
      Cr-Commit-Position: refs/heads/master@{#34632}
      4ec5a1e3
    • vogelheim's avatar
      Rework CallApi*Stubs. · 5096492f
      vogelheim authored
      - Eliminate stubs with a variable number of arguments.
        (That only worked due to their very limited use. These
         stubs' interface descriptors were basically lying
         about their number of args, which will fail when used
         generically.)
      - Fix all CallApi*Stubs' interface descriptors to no
        longer lie about their arguments.
      - Unify CallApi*Stub, for * in Function, Accessor,
        FunctionWithFixedArgs.
        (Since these are now all doing the same thing.)
      - Rename the unified stub (and interface descriptors) to
        *ApiCallback*, since that's really what they're doing.
      - Refuse inlining an API callback if its number of
        parameters exceeds the supported number of args.
      
      BUG=
      
      Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
      Cr-Commit-Position: refs/heads/master@{#34614}
      
      Review URL: https://codereview.chromium.org/1748123003
      
      Cr-Commit-Position: refs/heads/master@{#34627}
      5096492f
    • vogelheim's avatar
      Revert of Rework CallApi*Stubs. (patchset #5 id:100001 of... · 52a741d1
      vogelheim authored
      Revert of Rework CallApi*Stubs. (patchset #5 id:100001 of https://codereview.chromium.org/1748123003/ )
      
      Reason for revert:
      Breaks Chromium.
      
      Original issue's description:
      > Rework CallApi*Stubs.
      >
      > - Eliminate stubs with a variable number of arguments.
      >   (That only worked due to their very limited use. These
      >    stubs' interface descriptors were basically lying
      >    about their number of args, which will fail when used
      >    generically.)
      > - Fix all CallApi*Stubs' interface descriptors to no
      >   longer lie about their arguments.
      > - Unify CallApi*Stub, for * in Function, Accessor,
      >   FunctionWithFixedArgs.
      >   (Since these are now all doing the same thing.)
      > - Rename the unified stub (and interface descriptors) to
      >   *ApiCallback*, since that's really what they're doing.
      > - Refuse inlining an API callback if its number of
      >   parameters exceeds the supported number of args.
      >
      > BUG=
      >
      > Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
      > Cr-Commit-Position: refs/heads/master@{#34614}
      
      TBR=danno@chromium.org,jkummerow@chromium.org,mstarzinger@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1775933005
      
      Cr-Commit-Position: refs/heads/master@{#34624}
      52a741d1
    • vogelheim's avatar
      Rework CallApi*Stubs. · d238b953
      vogelheim authored
      - Eliminate stubs with a variable number of arguments.
        (That only worked due to their very limited use. These
         stubs' interface descriptors were basically lying
         about their number of args, which will fail when used
         generically.)
      - Fix all CallApi*Stubs' interface descriptors to no
        longer lie about their arguments.
      - Unify CallApi*Stub, for * in Function, Accessor,
        FunctionWithFixedArgs.
        (Since these are now all doing the same thing.)
      - Rename the unified stub (and interface descriptors) to
        *ApiCallback*, since that's really what they're doing.
      - Refuse inlining an API callback if its number of
        parameters exceeds the supported number of args.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1748123003
      
      Cr-Commit-Position: refs/heads/master@{#34614}
      d238b953
    • ishell's avatar
      [turbofan] [deoptimizer] Support inlining of ES6 tail calls. · c29a4560
      ishell authored
      In case when F was called with incompatible number of arguments (and therefore
      the arguments adator frame was created), F inlines a tail call of G which then
      deopts the deoptimizer should also remove the arguments adaptor frame for F.
      
      This CL adds required machinery to the deoptimizer.
      
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1768263004
      
      Cr-Commit-Position: refs/heads/master@{#34610}
      c29a4560
    • bmeurer's avatar
      [undetectable] Really get comparisons of document.all right now. · 679d9503
      bmeurer authored
      According to https://www.w3.org/TR/html5/obsolete.html#dom-document-all,
      comparisons of document.all to other values such as strings or objects,
      are unaffected. In fact document.all only gets special treatment in
      comparisons with null or undefined according to HTML. Especially setting
      the undetectable doesn't make two distinct JSReceivers equal.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1774273002
      
      Cr-Commit-Position: refs/heads/master@{#34608}
      679d9503
  15. 08 Mar, 2016 2 commits
    • mstarzinger's avatar
      [compiler] Remove support for concurrent OSR. · 26692242
      mstarzinger authored
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1773593002
      
      Cr-Commit-Position: refs/heads/master@{#34572}
      26692242
    • 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
  16. 07 Mar, 2016 2 commits
  17. 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