1. 22 Nov, 2018 1 commit
  2. 21 Nov, 2018 1 commit
  3. 12 Nov, 2018 1 commit
  4. 02 Oct, 2018 1 commit
  5. 17 Sep, 2018 1 commit
  6. 06 Jul, 2018 1 commit
  7. 28 Jun, 2018 1 commit
  8. 26 Jun, 2018 1 commit
  9. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored
      Currently each isolate stores its own array of
      {CallInterfaceDescriptorData}. This array has size 173, and each entry
      has 40 bytes. That's already 7kB per isolate.
      Additionally, each {CallInterfaceDescriptorData} allocates two
      heap-allocated arrays, which probably add up to more than the static
      size of the {CallInterfaceDescriptorData}. Note that all the
      {CallInterfaceDescriptorData} instances are initialized eagerly on
      isolate creation.
      
      Since {CallInterfaceDescriptor} is totally isolate independent itself,
      this CL refactors the current design to avoid a copy of them per
      isolate, and instead shares them process-wide. Still, we need to free
      the allocated heap arrays when the last isolate dies to avoid leaks.
      This can probably be refactored later by statically initializing more
      and avoiding the heap allocations all together.
      
      This refactoring will also allow us to use {CallInterfaceDescriptor}s
      from wasm background compilation threads, which are not bound to any
      isolate.
      
      R=mstarzinger@chromium.org, titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
      Reviewed-on: https://chromium-review.googlesource.com/1100879
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
  10. 14 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored
      This is a reland of 0909dbe3.
      Added missing V8_EXPORT_PRIVATE to AndroidLogStream.
      
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      >
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      >
      > R=mstarzinger@chromium.org
      >
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      Bug: v8:7820
      Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
      Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored
      This reverts commit 0909dbe3.
      
      Reason for revert: Blocks roll:
      https://chromium-review.googlesource.com/c/chromium/src/+/1099143
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      > 
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org
      
      Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7820
      Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  11. 13 Jun, 2018 1 commit
  12. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  13. 27 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] unify interpreter and JIT speculation poisoning · 1ef6c437
      Tobias Tebbi authored
      This CL changes the poisoning in the interpreter to use the
      infrastructure used in the JIT.
      
      This does not change the original flag semantics:
      
      --branch-load-poisoning enables JIT mitigations as before.
      
      --untrusted-code-mitigation enables the interpreter mitigations
        (now realized using the compiler back-end), but does not enable
        the back-end based mitigations for the Javascript JIT. So in effect
        --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
        use the same mechanics (including changed register allocation) that
        --branch-load-poisoning enables for the JIT.
      
      Bug: chromium:798964
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
      Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52243}
      1ef6c437
  14. 08 Mar, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] IA32 port of branch load poisoning. · 383ec7b5
      Jaroslav Sevcik authored
      The tricky part here is to take away one register from register
      allocation for the mask. The only problem is with calls that need
      an input operand to be passed in the poison register. For such calls,
      we change the register constraint in the instruction selector
      to pass the value in whatever place the register allocator sees fit.
      During code generation, we then copy the value from that place
      to the poison register. By that time, the mask is not necessary
      (once we bake the mask into the target, it should be done before
      this move).
      
      For the branches, the mask update does not use cmov (unlike x64)
      because cmov does not take an immediate and we do not have
      a scratch register. Instead we use bit-twiddling tricks
      (suggested by @tebbi). For example, here is the code for masking
      register update after a bailout on non-zero:
      
        jnz deopt_bailout    ;; Bailout branch
        setnz bl             ;; These three instructions update the mask
        add  ebx, 255
        sar  ebx, 31
      
      (On x64, the sequence is:
      
        jnz deopt_bailout
        mov r10, 0      ;; We have a scratch register for zero
        cmovnz r9, r10  ;; Set to zero if we execute this branch
                        ;; in branch mis-speculation
      )
      
      
      This CL also fixes a bug in register configuration, where we used
      to wrongly restrict the array of register name.
      
      Change-Id: I5fceff2faf8bdc527d9934afc284b749574ab69e
      Bug: chromium:798964
      Reviewed-on: https://chromium-review.googlesource.com/946251
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51798}
      383ec7b5
  15. 12 Feb, 2018 1 commit
    • Ross McIlroy's avatar
      [Ignition] [TurboFan] Generate speculation poison in code generator. · a021b6c4
      Ross McIlroy authored
      Moves generation of speculation poison to be based on the PC target vs the
      actual PC being executed. The speculation poison is generated in the prologue
      of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
      The result is stored in a known register, which can then be read using the
      SpeculationPoison machine node.
      
      Currently we need to ensure the SpeculationPoison node is scheduled right after
      the code prologue so that the poison register doesn't get clobbered. This is
      currently not verified, however it's only use is in RawMachineAssembler where
      it is manually scheduled early.
      
      The Ignition bytecode handlers are updated to use this speculation poison
      rather than one generated by comparing the target bytecode.
      
      BUG=chromium:798964
      
      Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
      Reviewed-on: https://chromium-review.googlesource.com/893160
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51229}
      a021b6c4
  16. 09 Feb, 2018 1 commit
  17. 01 Feb, 2018 1 commit
  18. 03 Aug, 2017 1 commit
  19. 30 Jun, 2017 1 commit
  20. 14 Jun, 2017 1 commit
  21. 31 May, 2017 1 commit
  22. 23 Feb, 2017 1 commit
  23. 05 Jan, 2017 1 commit
  24. 19 Dec, 2016 1 commit
  25. 05 Dec, 2016 1 commit
  26. 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
  27. 02 Nov, 2016 2 commits
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · fe552636
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40699}
      fe552636
    • machenbach's avatar
      Revert of [turbofan] Support variable size argument popping in TF-generated... · c61902e0
      machenbach authored
      Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ )
      
      Reason for revert:
      Seems to break arm64 sim debug and blocks roll:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
      
      Original issue's description:
      > [turbofan] Support variable size argument removal in TF-generated functions
      >
      > This is preparation for using TF to create builtins that handle variable number of
      > arguments and have to remove these arguments dynamically from the stack upon
      > return.
      >
      > The gist of the changes:
      > - Added a second argument to the Return node which specifies the number of stack
      >   slots to pop upon return in addition to those specified by the Linkage of the
      >   compiled function.
      > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
      >   handles all tail-call cases except where the return value type differs, this fallback
      >   was not really useful and in fact caused unexpected behavior with variable
      >   sized argument popping, since it wasn't possible to materialize a Return node
      >   with the right pop count from the TailCall without additional context.
      > - Modified existing Return generation to pass a constant zero as the additional
      >   pop argument since the variable pop functionality
      >
      > LOG=N
      
      TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      NOPRESUBMIT=true
      
      Review-Url: https://codereview.chromium.org/2473643002
      Cr-Commit-Position: refs/heads/master@{#40691}
      c61902e0
  28. 31 Oct, 2016 1 commit
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · 5319b50c
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40678}
      5319b50c
  29. 19 Sep, 2016 1 commit
  30. 25 Aug, 2016 1 commit
  31. 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
  32. 27 Jun, 2016 1 commit
  33. 20 Jun, 2016 1 commit
  34. 14 Jun, 2016 1 commit
  35. 13 Jun, 2016 2 commits
  36. 27 May, 2016 1 commit
  37. 24 Apr, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce TruncateTaggedToWord32 simplified operator. · 0231a7ef
      bmeurer authored
      This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
      trick that was used in the MachineOperatorReducer to combine the
      ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
      doing that later, we can just introduce the proper operator during the
      representation selection directly.
      
      Also separate the TruncateFloat64ToInt32 machine operator, which had two
      different meanings depending on a flag (either JavaScript truncation or
      C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
      represents the JavaScript truncation (implemented via TruncateDoubleToI
      macro + code stub) and the RoundFloat64ToInt32, which implements the C++
      round towards zero operation (in the same style as the other WebAssembly
      driven Round* machine operators).
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1919513002
      
      Cr-Commit-Position: refs/heads/master@{#35743}
      0231a7ef