1. 01 Mar, 2018 1 commit
    • Clemens Hammacher's avatar
      Fix is_trivially_copyable check for MSVC and older stdlibc++ · 9dd6f0d0
      Clemens Hammacher authored
      MSVC 2015 and 2017 implement std::is_trivially_copyable, but not
      correctly. Hence, reimplement it using more low-level primitives.
      
      For stdlibc++ versions below 5.0, we already have a workaround for the
      missing support of std::is_trivially_copyable, but this is an unsound
      approximation, because it is ignoring move constructor, move assignment
      and copy assignment. Therefore, do not use this approximation for
      asserting trivial copyability of a type.
      
      Finally, add unittests for the new is_trivially_copyable
      implementations.
      
      R=mstarzinger@chromium.org
      CC=loorongjie@gmail.com
      
      Change-Id: I9ee56a65882e8c94b72c9a2d484edd27963a5d89
      Reviewed-on: https://chromium-review.googlesource.com/941521Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51651}
      9dd6f0d0
  2. 13 Feb, 2018 1 commit
  3. 09 Feb, 2018 1 commit
  4. 22 Jan, 2018 1 commit
  5. 16 Jan, 2018 1 commit
  6. 20 Dec, 2017 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Preparation for padding of arguments" · f6879033
      Georgia Kouveli authored
      This is a reland of bcf11729
      
      The test was timing out in no snapshot builds, as each CodeAssemblerTester
      creates a new Context. Reduced the random iterations significantly.
      
      Original change's description:
      > [arm64] Preparation for padding of arguments
      >
      > As part of JSSP removal, we need to align the arguments passed to functions
      > on the stack, by adding a padding slot when the total number of arguments
      > is odd.
      >
      > This patch introduces the kPadArguments flag (which is currently set to
      > false for all architectures), which will control padding of arguments in
      > architecture-independent parts of the code (deoptimizer, instruction
      > selector).
      >
      > It also adds some executable tests for tail calls with various stack
      > parameter counts on the caller and callee sides.
      >
      > This will be turned on for arm64 together with arm64-specific changes to
      > the code generator, the MacroAsembler and the builtins, in a later patch.
      >
      > Bug: v8:6644
      > Change-Id: I79a5c149123fe8130cedd1ccffec3d9b50361e08
      > Reviewed-on: https://chromium-review.googlesource.com/806554
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50134}
      
      TBR=jarin@chromium.org
      
      Bug: v8:6644
      Change-Id: I795877ed9791e126ffac6841dbbb65189e95d207
      Reviewed-on: https://chromium-review.googlesource.com/833046
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50238}
      f6879033
  7. 16 Dec, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "[arm64] Preparation for padding of arguments" · fb8efb12
      Michael Achenbach authored
      This reverts commit bcf11729.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/16791
      
      The test cctest/test-run-tail-calls/FuzzStackParamCount hangs on
      the nosnap debug bot and times out.
      
      Original change's description:
      > [arm64] Preparation for padding of arguments
      > 
      > As part of JSSP removal, we need to align the arguments passed to functions
      > on the stack, by adding a padding slot when the total number of arguments
      > is odd.
      > 
      > This patch introduces the kPadArguments flag (which is currently set to
      > false for all architectures), which will control padding of arguments in
      > architecture-independent parts of the code (deoptimizer, instruction
      > selector).
      > 
      > It also adds some executable tests for tail calls with various stack
      > parameter counts on the caller and callee sides.
      > 
      > This will be turned on for arm64 together with arm64-specific changes to
      > the code generator, the MacroAsembler and the builtins, in a later patch.
      > 
      > Bug: v8:6644
      > Change-Id: I79a5c149123fe8130cedd1ccffec3d9b50361e08
      > Reviewed-on: https://chromium-review.googlesource.com/806554
      > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50134}
      
      TBR=rmcilroy@chromium.org,jarin@chromium.org,georgia.kouveli@arm.com
      
      Change-Id: Iff4d7da418204834822842b160eacb8980058172
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6644
      Reviewed-on: https://chromium-review.googlesource.com/830847Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50144}
      fb8efb12
  8. 15 Dec, 2017 1 commit
    • Georgia Kouveli's avatar
      [arm64] Preparation for padding of arguments · bcf11729
      Georgia Kouveli authored
      As part of JSSP removal, we need to align the arguments passed to functions
      on the stack, by adding a padding slot when the total number of arguments
      is odd.
      
      This patch introduces the kPadArguments flag (which is currently set to
      false for all architectures), which will control padding of arguments in
      architecture-independent parts of the code (deoptimizer, instruction
      selector).
      
      It also adds some executable tests for tail calls with various stack
      parameter counts on the caller and callee sides.
      
      This will be turned on for arm64 together with arm64-specific changes to
      the code generator, the MacroAsembler and the builtins, in a later patch.
      
      Bug: v8:6644
      Change-Id: I79a5c149123fe8130cedd1ccffec3d9b50361e08
      Reviewed-on: https://chromium-review.googlesource.com/806554
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50134}
      bcf11729
  9. 16 Oct, 2017 3 commits
    • Junliang Yan's avatar
      Reland "PPC/s390: Fix arguement handling" · 11291891
      Junliang Yan authored
      This is a reland of af49af00
      Original change's description:
      > PPC/s390: Fix arguement handling
      > 
      > 1. in AssembleMove and AssembleSwap, we need to distinguish Double and Float
      > 2. in 32-bit mode, double needs to be counted as 2 slots in stack
      > 
      > R=joransiu@ca.ibm.com, jbarboza@ca.ibm.com, michael_dawson@ca.ibm.com, mmallick@ca.ibm.com
      > 
      > Bug: 
      > Change-Id: Iffe1844aa72e9d4c9492034c3df9a994e1304a27
      > Reviewed-on: https://chromium-review.googlesource.com/720676
      > Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
      > Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      > Cr-Commit-Position: refs/heads/master@{#48593}
      
      Change-Id: If91125e71b82c92f54f537345e4c213bd185e786
      Reviewed-on: https://chromium-review.googlesource.com/721419Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#48610}
      11291891
    • Junliang Yan's avatar
      Revert "PPC/s390: Fix arguement handling" · 34ba7e94
      Junliang Yan authored
      This reverts commit af49af00.
      
      Reason for revert: <INSERT REASONING HERE>
      
      There is a mistake in codegen to cause error in snapshot.
      
      Original change's description:
      > PPC/s390: Fix arguement handling
      > 
      > 1. in AssembleMove and AssembleSwap, we need to distinguish Double and Float
      > 2. in 32-bit mode, double needs to be counted as 2 slots in stack
      > 
      > R=​joransiu@ca.ibm.com, jbarboza@ca.ibm.com, michael_dawson@ca.ibm.com, mmallick@ca.ibm.com
      > 
      > Bug: 
      > Change-Id: Iffe1844aa72e9d4c9492034c3df9a994e1304a27
      > Reviewed-on: https://chromium-review.googlesource.com/720676
      > Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
      > Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      > Cr-Commit-Position: refs/heads/master@{#48593}
      
      TBR=michael_dawson@ca.ibm.com,jyan@ca.ibm.com,joransiu@ca.ibm.com,jbarboza@ca.ibm.com,mmallick@ca.ibm.com
      
      Change-Id: I76b7eb96e7bfc15e3d2b07474543e996b9ea5f86
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/721140Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#48600}
      34ba7e94
    • Junliang Yan's avatar
      PPC/s390: Fix arguement handling · af49af00
      Junliang Yan authored
      1. in AssembleMove and AssembleSwap, we need to distinguish Double and Float
      2. in 32-bit mode, double needs to be counted as 2 slots in stack
      
      R=joransiu@ca.ibm.com, jbarboza@ca.ibm.com, michael_dawson@ca.ibm.com, mmallick@ca.ibm.com
      
      Bug: 
      Change-Id: Iffe1844aa72e9d4c9492034c3df9a994e1304a27
      Reviewed-on: https://chromium-review.googlesource.com/720676Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#48593}
      af49af00
  10. 13 Oct, 2017 2 commits
  11. 14 Sep, 2017 1 commit
  12. 09 Sep, 2017 1 commit
    • Anisha Rohra's avatar
      s390/PPC: Make Register et al. real classes · 0b491c89
      Anisha Rohra authored
      Port 9e995e12
      Port 408f252b
      
        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=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2e87efc8790290c64fd6c0a2d093326710b30ed3
      Reviewed-on: https://chromium-review.googlesource.com/658065Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47933}
      0b491c89
  13. 16 Aug, 2017 1 commit
  14. 02 Aug, 2017 1 commit
  15. 01 Aug, 2017 2 commits
  16. 24 Jul, 2017 2 commits
  17. 10 Jul, 2017 1 commit
    • Enrico Bacis's avatar
      [ppc] use Double instead of double in ppc compiler · 5457e8a9
      Enrico Bacis authored
      The use of double variables to store bit patterns may lead to bit flips
      when the stored bit pattern is a signaling NaN (sNaN). Operations on a
      sNaN variable (even just returning the variable from a function) may
      turn it into a quiet NaN (qNaN), flipping the signaling bit and
      affecting the information stored in the variable.
      
      We observed this behaviour on ia32 architectures and therefore in the
      simulator builds for other platforms. The use of the wrapper class
      Double should prevent this behaviour.
      
      R=ahaas@chromium.org
      
      Change-Id: Ibd1119924a59db771fd4c250689ad9c2a35fff75
      Reviewed-on: https://chromium-review.googlesource.com/562771Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Enrico Bacis <enricobacis@google.com>
      Cr-Commit-Position: refs/heads/master@{#46533}
      5457e8a9
  18. 29 Jun, 2017 1 commit
  19. 23 Jun, 2017 1 commit
  20. 08 Jun, 2017 1 commit
    • sampsong's avatar
      PPC/s390: [compiler] Delay allocation of code-embedded heap numbers. · ae947e26
      sampsong authored
      Port 659e8f7b
      
      Original Commit Message:
      
          Instead of allocating and embedding certain heap numbers into the code
          during code assembly, emit dummies but record the allocation requests.
          Later then, in Assembler::GetCode, allocate the heap numbers and patch
          the code by replacing the dummies with the actual objects. The
          RelocInfos for the embedded objects are already recorded correctly when
          emitting the dummies.
      
      R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:6048
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2929843002
      Cr-Commit-Position: refs/heads/master@{#45793}
      ae947e26
  21. 28 Apr, 2017 1 commit
  22. 30 Mar, 2017 1 commit
  23. 29 Mar, 2017 1 commit
  24. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
  25. 08 Mar, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [assembler] Make register definitions constexpr · e7be85da
      bjaideep authored
      Port e82b7ccd
      
      Original Commit Message:
      
          I originally needed this for the initialization of a constexpr array in
          the wasm lazy compile builtin, but since it's a bigger change, I now
          split it off as this separate CL.
          The style guide recommends constexpr over const. I thus apply the
          constexprificaton over all headers that I touched anyway.
      
          I also remove the ARM64_DEFINE_REG_STATICS hack. It was introduced when
          merging in arm64 support more than three years ago, and I don't see the
          purpose for this.
          Also, some #defines can now be constexpr definitions, which was not
          possible before according to the comment.
      
      R=clemensh@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2733323003
      Cr-Commit-Position: refs/heads/master@{#43678}
      e7be85da
  26. 27 Feb, 2017 1 commit
  27. 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
  28. 09 Feb, 2017 1 commit
  29. 13 Jan, 2017 1 commit
  30. 12 Jan, 2017 1 commit
  31. 22 Nov, 2016 1 commit
  32. 14 Nov, 2016 1 commit
    • tebbi's avatar
      This CL enables precise source positions for all V8 compilers. It merges... · c3a6ca68
      tebbi authored
      This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset.
      SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
       - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
       - The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
      Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
      
      If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
      So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
      
      All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
      
      At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
      
      I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
      
      The following additional changes were necessary:
       - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
       - The class HPositionInfo was effectively dead code and is now removed.
       - SourcePosition has new printing and information facilities, including computing a full inlining stack.
       - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
       - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
       - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
       - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
      
      BUG=v8:5432
      
      Review-Url: https://codereview.chromium.org/2451853002
      Cr-Commit-Position: refs/heads/master@{#40975}
      c3a6ca68
  33. 18 Aug, 2016 1 commit
  34. 18 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for eager/soft deoptimization reasons. · db635d5b
      bmeurer authored
      So far TurboFan wasn't adding the deoptimization reasons for eager/soft
      deoptimization exits that can be used by either the DevTools profiler or
      the --trace-deopt flag. This adds basic support for deopt reasons on
      Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
      the reasons to the code generation.
      
      Also moves the DeoptReason to it's own file (to resolve include cycles)
      and drops unused reasons.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2161543002
      Cr-Commit-Position: refs/heads/master@{#37823}
      db635d5b
  35. 30 Jun, 2016 1 commit