1. 17 Oct, 2018 1 commit
  2. 21 Sep, 2018 1 commit
    • Jakob Kummerow's avatar
      Fix building with GCC 7.x and 8.x · 9ed4b965
      Jakob Kummerow authored
      GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class
      either derives from a class or has a member field of a type that
      was declared in an anonymous namespace.
      It is also opposed (-Werror=attributes) to visibility attributes
      being defined at explicit template instantiations.
      GCC 8.x further has reservations (-Werror=class-memaccess) about
      letting memset/memcpy modify areas within non-POD objects.
      
      Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a
      Reviewed-on: https://chromium-review.googlesource.com/1208306
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56106}
      9ed4b965
  3. 19 Sep, 2018 1 commit
  4. 17 Sep, 2018 1 commit
  5. 30 Aug, 2018 1 commit
  6. 26 Jul, 2018 1 commit
  7. 15 Mar, 2018 1 commit
  8. 05 Mar, 2018 1 commit
  9. 13 Feb, 2018 1 commit
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, x64) · 8f489e73
      Mike Stanton authored
      This introduces masking of loads with speculation bit during code generation.
      At the moment, this is done only for x64 optimized code, under the
      --branch-load-poisoning flag.
      
      Overview of changes:
      - new register configuration configuration with one register reserved for
        the speculation poison/mask (kSpeculationPoisonRegister).
      - in codegen, we introduce an update to the poison register at the starts
        of all successors of branches (and deopts) that are marked as safety
        branches (deopts).
      - in memory optimizer, we lower all field and element loads to PoisonedLoads.
      - poisoned loads are then masked in codegen with the poison register.
        * only integer loads are masked at the moment.
      
      Bug: chromium:798964
      Change-Id: Ie51fdbde578fc289dff029794f3cfe8eaf33e1ef
      Reviewed-on: https://chromium-review.googlesource.com/901625
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51272}
      8f489e73
  10. 30 Jan, 2018 1 commit
    • Pierre Langlois's avatar
      [turbofan] Refactor AssembleMove and AssembleSwap · 16f2bcdb
      Pierre Langlois authored
      The way the code generator's AssembleMove and AssembleSwap methods are written
      makes it easy to forget which sort of move is being implemented when looking at
      a sequence of instructions. This patch is an attempt to address this by
      rewriting those methods using switch/case instead of a string of if/else.
      
      To do this, introduce new utility functions to detect what type of move to
      perform given a pair of InstructionOperands.
      
      Bug: 
      Change-Id: I32b146c86409e595b7b59a66bf43220899024fdd
      Reviewed-on: https://chromium-review.googlesource.com/749201
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50966}
      16f2bcdb
  11. 22 Jan, 2018 1 commit
  12. 09 Jan, 2018 1 commit
  13. 13 Dec, 2017 1 commit
  14. 21 Nov, 2017 1 commit
  15. 25 Sep, 2017 1 commit
  16. 13 Sep, 2017 1 commit
  17. 04 Sep, 2017 1 commit
  18. 20 Jul, 2017 1 commit
  19. 14 Jul, 2017 1 commit
  20. 13 Jul, 2017 1 commit
  21. 05 Jul, 2017 1 commit
  22. 30 Jun, 2017 1 commit
  23. 08 Jun, 2017 1 commit
    • bbudge's avatar
      [WASM] Eliminate SIMD boolean vector types. · 381f7da0
      bbudge authored
      - Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
      - All vector comparisons return v128 type.
      - Eliminates b1xN and, or, xor, not.
      - Selects take a v128 mask vector and are now bit-wise.
      - Adds a new test for Select, where mask is non-canonical (not 0's and -1's).
      
      LOG=N
      BUG=v8:6020
      
      Review-Url: https://codereview.chromium.org/2919203002
      Cr-Commit-Position: refs/heads/master@{#45795}
      381f7da0
  24. 07 Jun, 2017 1 commit
    • danno's avatar
      Inline Array.prototype.forEach in TurboFan · 90c3a2d5
      danno authored
      This CL contains a few pieces:
      
      - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
        graphs, which--when triggered--swizzle the values in the the FrameState to be
        parameters to a typically TF-generated builtin that resumes execution to finish
        the slow-case functionality.
      - Continuation builtins that have special handling in the deoptimizer and their own
        new frame type to ensure that the values they need to begin executing can be stashed
        away and restored immediately before the builtin is called via a trampoline that runs
        when the continuation builtin's frame execution resumes.
      - An implementation of Array.prototype.forEach in TurboFan that can be used to
        inline it. The inlined forEach implementation uses the checkpoints mechanism
        described above to deopt in the middle of the forEach in the cases that optimization
        invariants are violated. There is a slightly different continuation stub for each
        deopt point in the forEach implementation to ensure the correct side-effects, i.e.
        that the deopt of the builtin isn't programmatically observable.
      
      Review-Url: https://codereview.chromium.org/2803853005
      Cr-Commit-Position: refs/heads/master@{#45764}
      90c3a2d5
  25. 02 Jun, 2017 1 commit
  26. 25 May, 2017 2 commits
  27. 22 May, 2017 1 commit
  28. 01 May, 2017 1 commit
    • stanisc's avatar
      Remove padding in v8::internal::compiler::Constant class. · 9ede481a
      stanisc authored
      This makes the size of the class smaller by 8 bytes on 64-bit. I looked at the usage
      pattern. Even though it seems the number of instances doesn't get higher
      than a few thousand, this class is still very hot because it is constructed and
      passed by value a lot. So perhaps reducing the size would make passing this
      class by value or growing arrays more optimal and might save some cycles.
      
      Before:
          class v8::internal::compiler::Constant [sizeof = 24] {
            [sizeof=4] v8::internal::compiler::Constant::Type type_
            <padding> (4 bytes)
            [sizeof=8] __int64 value_
            [sizeof=4] v8::internal::RelocInfo::Mode rmode_
            <padding> (4 bytes)
          }
      
      After:
          class v8::internal::compiler::Constant [sizeof = 16] {
            [sizeof=4] v8::internal::compiler::Constant::Type type_
            [sizeof=4] v8::internal::RelocInfo::Mode rmode_
            [sizeof=8] __int64 value_
          }
      
      BUG=chromium:710933
      
      Review-Url: https://codereview.chromium.org/2841343002
      Cr-Commit-Position: refs/heads/master@{#45001}
      9ede481a
  29. 27 Mar, 2017 1 commit
  30. 03 Mar, 2017 1 commit
  31. 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
  32. 21 Feb, 2017 1 commit
    • bbudge's avatar
      [V8] Implement SIMD Boolean vector types to allow mask registers. · 9fe0b4c7
      bbudge authored
      - Adds new machine types SimdBool4/8/16 for the different boolean vector types.
      - Adds a kSimdMaskRegisters flag for each platform. These are all false for now.
      - Removes Create, ExtractLane, ReplaceLane, Equal, NotEqual, Swizzle and Shuffle
        opcodes from the Boolean types. These are unlikely to be well supported natively,
        and can be synthesized using Select.
      - Changes the signature of Relational opcodes to return boolean vectors.
      - Changes the signature of Select opcodes to take boolean vectors.
      - Updates the ARM implementation of Relational and Select opcodes.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2700813002
      Cr-Commit-Position: refs/heads/master@{#43348}
      9fe0b4c7
  33. 10 Feb, 2017 1 commit
  34. 09 Feb, 2017 2 commits
  35. 26 Jan, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce JSCallForwardVarargs operator. · 69747e26
      bmeurer authored
      We turn a JSCallFunction node for
      
        f.apply(receiver, arguments)
      
      into a JSCallForwardVarargs node, when the arguments refers to the
      arguments of the outermost optimized code object, i.e. not an inlined
      arguments, and the apply method refers to Function.prototype.apply,
      and there's no other user of arguments except in frame states.
      
      We also replace the arguments node in the graph with a marker for
      the Deoptimizer similar to Crankshaft to make sure we don't materialize
      unused arguments just for the sake of deoptimization. We plan to replace
      this with a saner EscapeAnalysis based solution soon.
      
      R=jarin@chromium.org
      BUG=v8:5267,v8:5726
      
      Review-Url: https://codereview.chromium.org/2655233002
      Cr-Commit-Position: refs/heads/master@{#42680}
      69747e26
  36. 20 Jan, 2017 1 commit
  37. 19 Jan, 2017 2 commits