1. 21 May, 2019 1 commit
  2. 20 May, 2019 1 commit
  3. 17 May, 2019 2 commits
  4. 03 Jul, 2018 1 commit
  5. 10 Jul, 2017 1 commit
  6. 22 May, 2017 1 commit
  7. 16 Mar, 2017 1 commit
  8. 09 Mar, 2017 1 commit
  9. 28 Feb, 2017 1 commit
    • tebbi's avatar
      [turbofan] escape analysis supports arguments object and rest elements · 7467f16d
      tebbi authored
      The new NewUnmappedArgumentsElements node now takes two inputs:
      - the frame holding the arguments (current frame or arguments adaptor frame)
      - the length of the suffix of passed arguments to be copied into the backing store
      
      These inputs are computed with two new node types:
      ArgumentsFrame()
      ArgumentsLength[formal_parameter_count,is_rest_length](Node* arguments_frame)
      The node type NewRestParameterElements can now be expressed with NewUnmappedArgumentsElements and an appropriate length and is thus not needed anymore.
      
      In escape analysis, we lower loads from the length field of NewUnmappedArgumentsElements with its length input and if we find out that no write access to the arguments elements exists, we replace element loads with direct stack access and replace the NewUnmappedArgumentsElements node with a node of the new node type ArgumentsElementsState. This corresponds to an ObjectState node and gets translated into a deoptimizer instruction to allocate the backing store. Together with the already existing deoptimizer support for the actual arguments object/rest parameters, this allows to remove all allocations for arguments objects/rest parameters in this case.
      In the deoptimizer, we read the actual parameters from the stack while transforming the static deopt info into TranslatedValue objects.
      
      If escape analysis cannot remove the backing store allocation, NewUnmappedArgumentsElements gets lo
      
      BUG=v8:5726
      
      Review-Url: https://codereview.chromium.org/2692753004
      Cr-Commit-Position: refs/heads/master@{#43475}
      7467f16d
  10. 23 Feb, 2017 1 commit
  11. 21 Feb, 2017 1 commit
  12. 17 Feb, 2017 1 commit
  13. 21 Dec, 2016 1 commit
  14. 15 Dec, 2016 1 commit
  15. 14 Dec, 2016 1 commit
  16. 12 Dec, 2016 1 commit
  17. 08 Dec, 2016 1 commit
  18. 06 Dec, 2016 1 commit
  19. 16 Nov, 2016 2 commits
  20. 15 Nov, 2016 1 commit
  21. 09 Sep, 2016 1 commit
  22. 08 Sep, 2016 1 commit
  23. 12 Aug, 2016 1 commit
  24. 09 Aug, 2016 1 commit
  25. 08 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add initial support for growing stores. · e6822a83
      bmeurer authored
      Introduce a dedicated MaybeGrowFastElements simplified operator, which
      tries to grow a fast elements backing store for a given element that
      should be added to an array/object. Use that to lower a growing keyed
      store to a sequence of
      
       1) check index is a valid array index,
       2) check stored value,
       3) maybe grow elements backing store (and deoptimize if it would
          normalize), and
       4) store the actual element.
      
      The actual growing is done by two dedicated GrowFastDoubleElements
      and GrowFastSmiOrObjectElements builtins, which are very similar to
      the GrowArrayElementsStub that is used by Crankshaft.
      
      Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements
      builtin, similar to the new growing builtins, so we don't need to
      inline the store+write barrier for the elements into all optimized
      code objects anymore.
      
      Also fix a bug in the OperationTyper for NumberSilenceNaN, which was
      triggered by this change.
      
      BUG=v8:5272
      
      Review-Url: https://codereview.chromium.org/2227493002
      Cr-Commit-Position: refs/heads/master@{#38418}
      e6822a83
  26. 05 Aug, 2016 3 commits
  27. 02 Aug, 2016 1 commit
  28. 25 Jul, 2016 1 commit
  29. 20 Jul, 2016 1 commit