1. 13 Dec, 2017 1 commit
  2. 22 May, 2017 1 commit
  3. 10 Feb, 2017 1 commit
  4. 09 Feb, 2017 2 commits
  5. 25 Jan, 2017 1 commit
  6. 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
  7. 03 Nov, 2016 1 commit
  8. 24 Aug, 2016 1 commit
  9. 02 Aug, 2016 1 commit
  10. 25 Jul, 2016 1 commit
  11. 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
  12. 14 Jul, 2016 1 commit
  13. 13 Jul, 2016 1 commit
  14. 11 Jul, 2016 1 commit
    • danno's avatar
      [turbofan] Add MachineType to LinkageLocation · 3e2085eb
      danno authored
      By adding MachineType to LinkageLocation, it is possible not only to reason
      about the location of a LinkageLocation on the stack, but also about it's
      size. This will be useful in follow-on CLs that attempt to merge some of the
      parameter passing logic of tail calls and normal (non-tail) calls.
      
      As a nice side-effect, it is no longer necessary to separately keep a
      MachineSignature in a CallDescriptor, because the MachineTypes contianed in
      LinkageLocation for all of the Descriptor's parameters and return types are
      sufficient. This CL therefore removes the MachineSignature from the
      CallDescriptor and adjusts all the calling code accordingly, simplifying and
      de-duplicating code in a bunch of places.
      
      R=titzer@chromium.org, bmeurer@chromium.org
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2124023003
      Cr-Commit-Position: refs/heads/master@{#37633}
      3e2085eb
  15. 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
  16. 09 Jun, 2016 1 commit
  17. 27 May, 2016 1 commit
  18. 12 Apr, 2016 2 commits
  19. 11 Apr, 2016 1 commit
  20. 01 Apr, 2016 2 commits
  21. 24 Feb, 2016 1 commit
  22. 10 Dec, 2015 1 commit
    • jarin's avatar
      [turbofan] Make MachineType a pair of enums. · bb2a830d
      jarin authored
      MachineType is now a class with two enum fields:
      - MachineRepresentation
      - MachineSemantic
      
      Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
      - register allocator now uses just the representation.
      - Phi and Select nodes only refer to representations.
      
      Review URL: https://codereview.chromium.org/1513543003
      
      Cr-Commit-Position: refs/heads/master@{#32738}
      bb2a830d
  23. 20 Nov, 2015 1 commit
  24. 13 Nov, 2015 1 commit
    • mtrofin's avatar
      [turbofan] Spill rsi and rdi in their existing locations. · 20f3a077
      mtrofin authored
      We push the context and the js function onto the stack as part of the
      frame construction. The register allocator is presented with virtual
      registers for the above as defined from their corresponding registers. It
      then goes on to spilling them somewhere else on the stack.
      
      This means each function spends two redundant spills and two
      unnecessary stack slots.
      
      This change addresses this issue.
      
      We present these parameters (context and function) to the register
      allocator as an UnallocatedOperand having a "secondary storage". The
      secondary storage is then associated to the live range as its
      spill operand. We capture the definition of the live range so that we can
      then commit the spill (in this case, eliminate) through a variation of the
      mechanics of the CommitAssignment phase.
      
      The register allocator validator also needed update to understand
      UnallocatedOperands with a secondary storage.
      
      The change renames the SpillAtDefinitionList and related APIs to better
      capture their intent - the old names suggested spills happened upon
      calling. In reality, potential spill locations were thus recorded, and later
      committed (or not, in certain cases) after register allocation.
      
      BUG= v8:4548
      LOG=n
      
      Review URL: https://codereview.chromium.org/1426943010
      
      Cr-Commit-Position: refs/heads/master@{#31988}
      20f3a077
  25. 04 Nov, 2015 1 commit
  26. 27 Oct, 2015 1 commit
    • danno's avatar
      [turbofan] Create ExplicitOperands to specify operands without virtual registers · f1aa5562
      danno authored
      Up until now, if one wanted to specify an explicit stack location                                                                                                                                                                                                or register as an operand for an instruction, it had to also be
      explicitly associated with a virtual register as a so-called
      FixedRegister or FixedStackSlot.
      
      For the implementation of tail calls, the plan is to use the gap
      resolver needs to shuffle stack locations from the caller to the
      tail-called callee. In order to do this, it must be possible to
      explicitly address operand locations on the stack that are not
      associated with virtual registers.
      
      This CL introduces ExplictOperands, which can specify a specific
      register or stack location that is not associated with virtual
      register. This will allow tail calls to specify the target
      locations for the necessary stack moves in the gap for the tail
      call without the core register allocation having to know about
      the target of the stack moves at all.
      
      In the process this CL:
      * creates a new Operand kind, ExplicitOperand, with which
        instructions can specify register and stack slots without an
        associated virtual register.
      * creates a LocationOperand class from which AllocatedOperand and
        ExplicitOperand are derived and provides a common interface to
        get Register, DoubleRegister and spill slot information.
      * removes RegisterOperand, DoubleRegisterOperand,
        StackSlotOperand and DoubleStackSlotOperand, they are subsumed
        by LocationOperand.
      * addresses a cleanup TODO in AllocatedOperand to reduce the
        redundancy of AllocatedOperand::Kind by using machine_type() to
        determine if an operand corresponds to a general purpose or
        double register.
      
      BUG=v8:4076
      LOG=n
      
      Review URL: https://codereview.chromium.org/1389373002
      
      Cr-Commit-Position: refs/heads/master@{#31603}
      f1aa5562
  27. 15 Oct, 2015 1 commit
  28. 02 Oct, 2015 3 commits
    • danno's avatar
      Re-reland: Remove register index/code indirection · 5cf1c0bc
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      Cr-Commit-Position: refs/heads/master@{#30913}
      
      Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
      Cr-Commit-Position: refs/heads/master@{#31075}
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#31087}
      5cf1c0bc
    • danno's avatar
      Revert of Reland: Remove register index/code indirection (patchset #20... · 00e07b00
      danno authored
      Revert of Reland: Remove register index/code indirection (patchset #20 id:380001 of https://codereview.chromium.org/1287383003/ )
      
      Reason for revert:
      Failures on MIPS
      
      Original issue's description:
      > Remove register index/code indirection
      >
      > Previous to this patch, both the lithium and TurboFan register
      > allocators tracked allocated registers by "indices", rather than
      > the register codes used elsewhere in the runtime. This patch
      > ensures that codes are used everywhere, and in the process cleans
      > up a bunch of redundant code and adds more structure to how the
      > set of allocatable registers is defined.
      >
      > Some highlights of changes:
      >
      > * TurboFan's RegisterConfiguration class moved to V8's top level
      >   so that it can be shared with Crankshaft.
      > * Various "ToAllocationIndex" and related methods removed.
      > * Code that can be easily shared between Register classes on
      >   different platforms is now shared.
      > * The list of allocatable registers on each platform is declared
      >   as a list rather than implicitly via the register index <->
      >   code mapping.
      >
      > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      > Cr-Commit-Position: refs/heads/master@{#30913}
      >
      > Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
      > Cr-Commit-Position: refs/heads/master@{#31075}
      
      TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1380863004
      
      Cr-Commit-Position: refs/heads/master@{#31083}
      00e07b00
    • danno's avatar
      Remove register index/code indirection · 7b7a8205
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      Cr-Commit-Position: refs/heads/master@{#30913}
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#31075}
      7b7a8205
  29. 24 Sep, 2015 2 commits
    • danno's avatar
      Revert of Remove register index/code indirection (patchset #17 id:320001 of... · 3ac27431
      danno authored
      Revert of Remove register index/code indirection (patchset #17 id:320001 of https://codereview.chromium.org/1287383003/ )
      
      Reason for revert:
      Failures on greedy RegAlloc, Fuzzer
      
      Original issue's description:
      > Remove register index/code indirection
      >
      > Previous to this patch, both the lithium and TurboFan register
      > allocators tracked allocated registers by "indices", rather than
      > the register codes used elsewhere in the runtime. This patch
      > ensures that codes are used everywhere, and in the process cleans
      > up a bunch of redundant code and adds more structure to how the
      > set of allocatable registers is defined.
      >
      > Some highlights of changes:
      >
      > * TurboFan's RegisterConfiguration class moved to V8's top level
      >   so that it can be shared with Crankshaft.
      > * Various "ToAllocationIndex" and related methods removed.
      > * Code that can be easily shared between Register classes on
      >   different platforms is now shared.
      > * The list of allocatable registers on each platform is declared
      >   as a list rather than implicitly via the register index <->
      >   code mapping.
      >
      > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      > Cr-Commit-Position: refs/heads/master@{#30913}
      
      TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1365073002
      
      Cr-Commit-Position: refs/heads/master@{#30914}
      3ac27431
    • danno's avatar
      Remove register index/code indirection · 80bc6f6e
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#30913}
      80bc6f6e
  30. 23 Sep, 2015 1 commit
    • pierre.langlois's avatar
      [arm64] Optimize fcmp when lhs operand is #0.0 · e28ae8ca
      pierre.langlois authored
      This patch checks the type of the lhs operand of a floating point
      comparison, and commutes the operands if it is #0.0.  It allows us to
      optimize a comparison with zero, as the fcmp instruction accepts #0.0 as
      rhs operand.
      
      Code before for "0.0 < 0.123":
      ------------------------------
      fmov d1, xzr
      ldr d0, pc+96
      fcmp d1, d0
      b.lo #+0xc
      
      Code after:
      -----------
      ldr d0, pc+92
      fcmp d0, #0.0
      b.gt #+0xc
      
      Before this patch, we used unsigned condition codes for floating point
      comparisons, but the unordered case was not correctly commuted.
      
      Review URL: https://codereview.chromium.org/1356283003
      
      Cr-Commit-Position: refs/heads/master@{#30881}
      e28ae8ca
  31. 31 Aug, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Remove usage of Unique<T> from graph. · 6e65e6db
      mstarzinger authored
      The usage of Unique<T> throughout the TurboFan IR does not have any
      advantage. There is no single point in time when they are initialized
      and most use-sites looked through to the underlying Handle<T> anyways.
      Also there already was a mixture of Handle<T> versus Unique<T> in the
      graph and this unifies the situation to use Handle<T> everywhere.
      
      R=bmeurer@chromium.org,titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1314473007
      
      Cr-Commit-Position: refs/heads/master@{#30458}
      6e65e6db
  32. 31 Jul, 2015 1 commit
  33. 30 Jul, 2015 1 commit
    • danno's avatar
      [turbofan]: Add better encapsulation to LinkageLocation · 3c9f69d3
      danno authored
      Add factory methods for different types of LinkageLocations, and ensure that
      accesses to the underlying data in the location are classified by type and
      funneled through explicit accessors.
      
      Also change the representation of LinkageLocation to use a BitField rather
      than using a reserved section of the integer range.
      
      Review URL: https://codereview.chromium.org/1262343002
      
      Cr-Commit-Position: refs/heads/master@{#29938}
      3c9f69d3
  34. 29 Apr, 2015 1 commit