1. 17 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Add a kCallBuiltinPointer call kind · f323a5f4
      Jakob Gruber authored
      Currently, Torque's builtin pointers store a Code target underneath and
      callsites generate a kArchCallCodeObject opcode. When embedded builtins
      are enabled, the call thus first calls the on-heap trampoline, which
      finally jumps to the target off-heap builtin code.
      
      This will no longer be possible in jitless mode, since on-heap code must
      not be executable.
      
      As a step towards changing the way builtin pointers are called
      (function pointers will hold the builtin index as a Smi, and callsites
      look up the off-heap target address and jump there), this CL adds a
      dedicated opcode for builtin pointer calls to the compiler pipeline.
      
      The calling mechanism itself is unchanged, changes there will happen
      in a follow-up.
      
      Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.
      
      Bug: v8:7777
      Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
      Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58281}
      f323a5f4
  2. 12 Nov, 2018 1 commit
  3. 19 Jun, 2018 1 commit
  4. 15 Jun, 2018 1 commit
  5. 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
  6. 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
  7. 20 Mar, 2018 1 commit
  8. 23 Feb, 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. 02 Jan, 2018 1 commit
  11. 12 Dec, 2017 1 commit
  12. 21 Nov, 2017 1 commit
  13. 24 Aug, 2017 1 commit
  14. 21 Aug, 2017 1 commit
  15. 20 Jul, 2017 1 commit
  16. 18 Jul, 2017 1 commit
  17. 11 Apr, 2017 1 commit
  18. 16 Mar, 2017 1 commit
  19. 07 Mar, 2017 1 commit
  20. 13 Feb, 2017 1 commit
    • bbudge's avatar
      [Turbofan] Add more non-arithmetic SIMD operations. · 11f88ef5
      bbudge authored
      - Renames select, swizzle, and shuffle to be consistent with the S128 and
        existing S32x4 ops, and reflect that these aren't arithmetic.
        e.g. I16x8Swizzle -> S16x8Swizzle.
      - Implements S16x8 and S8x16 Select operations and tests.
      - Implements S128And, Or, Xor, Not operations and tests.
      - Implements Swizzle for 32x4 formats.
      - Refactors test macros that generate SIMD code.
      
      TEST=cctest/test-run-wasm-simd/*
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2683713003
      Cr-Commit-Position: refs/heads/master@{#43168}
      11f88ef5
  21. 15 Dec, 2016 1 commit
    • ahaas's avatar
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. · 7bd61b60
      ahaas authored
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2562393002
      Cr-Commit-Position: refs/heads/master@{#41720}
      7bd61b60
  22. 26 Oct, 2016 1 commit
  23. 17 Oct, 2016 1 commit
  24. 25 Aug, 2016 3 commits
    • jarin's avatar
      Reland of [turbofan] Insert dummy values when changing from None type. · 2a97b1bc
      jarin authored
      This reverts commit a55fdb1e, relands
      https://codereview.chromium.org/2266823002/.
      
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2277283002
      Cr-Commit-Position: refs/heads/master@{#38917}
      2a97b1bc
    • bmeurer's avatar
      Revert of [turbofan] Insert dummy values when changing from None type.... · a55fdb1e
      bmeurer authored
      Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ )
      
      Reason for revert:
      Octane/Mandreel aborts with an exception now:
      
      TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function
      
      Original issue's description:
      > [turbofan] Insert dummy values when changing from None type.
      >
      > Currently we choose the MachineRepresentation::kNone representation for
      > values of Type::None, and when converting values from the kNone representation
      > we use "impossible" conversions that will crash at runtime. This
      > assumes that the impossible conversions should never be hit (the only
      > way to produce the impossible values is to perform an always-failing
      > runtime check on a value, such as Smi-checking a string). Note that
      > this assumes that the runtime check is executed before the impossible
      > convesrion.
      >
      > Introducing BitwiseOr type feedback broke this in two ways:
      >
      > - we always pick Word32 representation for bitwise-or, so the
      >   impossible conversion does not trigger (it only triggers with
      >   None representation), and we could end up with unsupported
      >   conversions from Word32.
      >
      > - even if we inserted impossible conversions, they are pure conversions.
      >   Since untagging, bitwise-or operations are also pure, we could hoist
      >   all these before the smi check of the inputs and we could hit the
      >   impossible conversions before we get to the smi check.
      >
      > This CL addresses this by just providing dummy values for conversions
      > from the Type::None type. It also removes the impossible-to-* conversions.
      >
      > BUG=chromium:638132
      >
      > Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
      > Cr-Commit-Position: refs/heads/master@{#38883}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2280613002
      Cr-Commit-Position: refs/heads/master@{#38893}
      a55fdb1e
    • jarin's avatar
      [turbofan] Insert dummy values when changing from None type. · c83b21ab
      jarin authored
      Currently we choose the MachineRepresentation::kNone representation for
      values of Type::None, and when converting values from the kNone representation
      we use "impossible" conversions that will crash at runtime. This
      assumes that the impossible conversions should never be hit (the only
      way to produce the impossible values is to perform an always-failing
      runtime check on a value, such as Smi-checking a string). Note that
      this assumes that the runtime check is executed before the impossible
      convesrion.
      
      Introducing BitwiseOr type feedback broke this in two ways:
      
      - we always pick Word32 representation for bitwise-or, so the
        impossible conversion does not trigger (it only triggers with
        None representation), and we could end up with unsupported
        conversions from Word32.
      
      - even if we inserted impossible conversions, they are pure conversions.
        Since untagging, bitwise-or operations are also pure, we could hoist
        all these before the smi check of the inputs and we could hit the
        impossible conversions before we get to the smi check.
      
      This CL addresses this by just providing dummy values for conversions
      from the Type::None type. It also removes the impossible-to-* conversions.
      
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2266823002
      Cr-Commit-Position: refs/heads/master@{#38883}
      c83b21ab
  25. 25 Jul, 2016 1 commit
  26. 01 Jul, 2016 1 commit
    • bmeurer's avatar
      [builtins] Unify most of the remaining Math builtins. · 0a0fe8fb
      bmeurer authored
      Import fdlibm versions of acos, acosh, asin and asinh, which are more
      precise and produce the same result across platforms (we were using
      libm versions for asin and acos so far, where both speed and precision
      depended on the operating system so far). Introduce appropriate TurboFan
      operators for these functions and use them both for inlining and for the
      generic builtin.
      
      Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
      to ensure that their behavior is always exactly the same as the inlined
      TurboFan version (i.e. C++ truncation semantics for double to float
      don't necessarily meet the JavaScript semantics).
      
      For completeness, also migrate Math.sign, which can even get some nice
      love in TurboFan.
      
      Drive-by-fix: Some alpha-sorting on the Math related functions, and
      cleanup the list of Math intrinsics that we have to export via the
      native context currently.
      
      BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
      TBR=rossberg@chromium.org
      R=franzih@chromium.org
      
      Review-Url: https://codereview.chromium.org/2116753002
      Cr-Commit-Position: refs/heads/master@{#37476}
      0a0fe8fb
  27. 30 Jun, 2016 1 commit
  28. 29 Jun, 2016 1 commit
    • georgia.kouveli's avatar
      [arm64] Generate adds/ands. · 317dc057
      georgia.kouveli authored
      Perform the following transformation:
      
          | Before           | After               |
          |------------------+---------------------|
          | add w2, w0, w1   | adds w2, w0, w1     |
          | cmp w2, #0x0     | b.<cond'> <addr>    |
          | b.<cond> <addr>  |                     |
          |------------------+---------------------|
          | add w2, w0, w1   | adds w2, w0, w1     |
          | cmp #0x0, w2     | b.<cond'> <addr>    |
          | b.<cond> <addr>  |                     |
      
      and the same for and instructions instead of add.  When the result of the
      add/and is not used, generate cmn/tst instead. We need to take care with which
      conditions we can handle and what new condition we map them to.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2065243005
      Cr-Commit-Position: refs/heads/master@{#37400}
      317dc057
  29. 28 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      bmeurer authored
      Introduce a new machine operator Float64Pow that for now is backed by
      the existing MathPowStub to start the unification of Math.pow, and at
      the same time address the main performance issue that TurboFan still has
      with the imaging-darkroom benchmark in Kraken.
      
      Also migrate the Math.pow builtin itself to a TurboFan builtin and
      remove a few hundred lines of hand-written platform code for special
      handling of the fullcodegen Math.pow version.
      
      BUG=v8:3599,v8:5086,v8:5157
      
      Review-Url: https://codereview.chromium.org/2103733003
      Cr-Commit-Position: refs/heads/master@{#37323}
      e607e12e
  30. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
      operator based on that, similar to what we do for Float64Cos and Float64Sin.
      Rewrite Math.tan() as TurboFan builtin and use those operators to also
      inline Math.tan() into optimized TurboFan functions.
      
      Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
      the %ConstructDouble runtime entry for writing tests.
      
      BUG=v8:5086,v8:5126
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2083453002
      Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc
  31. 17 Jun, 2016 3 commits
  32. 16 Jun, 2016 3 commits
  33. 13 Jun, 2016 2 commits
    • bmeurer's avatar
      [builtins] Introduce proper Float64Atan and Float64Atan2 operators. · 89d8c57b
      bmeurer authored
      Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
      introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
      similar to what we already did for Float64Log and Float64Log1p. Rewrite
      Math.atan() and Math.atan2() as TurboFan builtin and use the operators
      to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5095
      
      Review-Url: https://codereview.chromium.org/2065503002
      Cr-Commit-Position: refs/heads/master@{#36916}
      89d8c57b
    • bmeurer's avatar
      [builtins] Introduce proper Float64Log1p operator. · 7ceed92a
      bmeurer authored
      Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.log1p() as TurboFan builtin and use that operator to also
      inline Math.log1p() into optimized TurboFan functions.
      
      Also unify the handling of the special IEEE 754 functions somewhat in
      the TurboFan backends. At some point we can hopefully express this
      completely in the InstructionSelector (once we have an idea what to do
      with the ST(0) return issue on IA-32/X87).
      
      Drive-by-fix: Add some more test coverage for the log function.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5092
      
      Review-Url: https://codereview.chromium.org/2060743002
      Cr-Commit-Position: refs/heads/master@{#36914}
      7ceed92a