1. 16 Nov, 2015 2 commits
    • ahaas's avatar
      [turbofan] Added the optional Float64RoundTiesEven operator to turbofan. · dffecf31
      ahaas authored
      The TiesEven rounding mode rounds float64 numbers to the nearest
      integer. If there are two nearest integers, then the number is rounded
      to the even one.  This is the default rounding mode according to
      IEEE~754.
      
      I implemented the operator on ia32, x64, arm, arm64, mips, and mips64.
      
      I think there is a bug in the current implementation of the ppc
      simulator, which kept me from implementing the operator on ppc.
      According to my understanding of the ppc instruction manual, the FRIN
      instruction provides the right behavior for Float64RoundTiesEven. In the
      simulator, however, FRIN provides a different semantics. If there are
      two nearest integers, then the simulator returns the one which is
      further away form 0.
      
      Review URL: https://codereview.chromium.org/1440293002
      
      Cr-Commit-Position: refs/heads/master@{#32005}
      dffecf31
    • ahaas's avatar
      [turbofan] Added the optional Float64RoundUp operator to turbofan. · 1389b9f5
      ahaas authored
      I implemented it on x64, ia32, arm, arm64, mips, mips64, and ppc.
      
      Review URL: https://codereview.chromium.org/1444583002
      
      Cr-Commit-Position: refs/heads/master@{#32004}
      1389b9f5
  2. 13 Nov, 2015 1 commit
    • danno's avatar
      [turbofan] Better and more sane support for tail calls · ff283f7d
      danno authored
      * Limit triggering of tail calls to explicit use of a new inline runtime
        function %_TailCall. %_TailCall works just like %_Call except for using
        tail-calling mechanics (currently only in TF).
      * Remove hack that recognized some specific usages of %_Call and converted them
        into tail calls.
      * Support tail calls for all calls where the number of callee stack parameters
        is less than or equal to the number of caller stack parameters.
      * Use the gap resolver to swizzle parameters and registers to tail calls.
      
      BUG=v8:4076
      LOG=n
      
      Review URL: https://codereview.chromium.org/1439613003
      
      Cr-Commit-Position: refs/heads/master@{#31987}
      ff283f7d
  3. 10 Nov, 2015 1 commit
  4. 26 Oct, 2015 2 commits
  5. 19 Oct, 2015 1 commit
    • jarin's avatar
      [turbofan] Introduce lazy bailout, masked as a call. · f9a9c6be
      jarin authored
      This introduces an explicit lazy bailout. It is wrapped in the call
      node, mostly because the lazy deoptimization processing is married
      to the call processing in the instruction selector and the code generator.
      
      It is still a terrible hack.
      
      R=bmeurer@chromium.org,mstarzinger@chromium.org
      BUG=chromium:543994,v8:4195
      LOG=n
      
      Review URL: https://codereview.chromium.org/1412443003
      
      Cr-Commit-Position: refs/heads/master@{#31353}
      f9a9c6be
  6. 16 Oct, 2015 1 commit
  7. 15 Oct, 2015 1 commit
  8. 29 Sep, 2015 1 commit
    • jacob.bramley's avatar
      [arm] Fix a double-register push operation. · f20d6461
      jacob.bramley authored
      It is not safe to access memory below sp, and this is also forbidden by
      the ABI. When pushing, we must either use an atomic operation (such as
      vstm+db_w) or move sp before writing the data.
      
      This patch fixes one stack access, and also adds vpush and vpop helpers
      to simplify similar code.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1378563002
      
      Cr-Commit-Position: refs/heads/master@{#31008}
      f20d6461
  9. 24 Sep, 2015 2 commits
    • pierre.langlois's avatar
      [arm] Optimize vcmp when lhs operand is #0.0 · d1472d65
      pierre.langlois authored
      This patch checks the type of the lhs operand of a floating point
      comparison for ARM, and commutes the operands if it is #0.0.  It allows
      us to optimize a comparison with zero, as the vcmp instruction
      accepts #0.0 as rhs operand.
      
      Code before for "0.0 < 0.123":
      ------------------------------
      movw ip, #29360
      movt ip, #37224
      movw r9, #31981
      movt r9, #16319
      vmov d0, ip, r9
      mov ip, #0
      vmov d1, ip, ip
      vcmp.f64 d1, d0
      vmrs APSR, FPSCR
      bcc +12
      
      Code after:
      -----------
      movw ip, #29360
      movt ip, #37224
      movw r9, #31981
      movt r9, #16319
      vmov d0, ip, r9
      vcmp.f64 d0, #0.0
      vmrs APSR, FPSCR
      bgt +12
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1361913003
      
      Cr-Commit-Position: refs/heads/master@{#30911}
      d1472d65
    • martyn.capewell's avatar
      [turbofan] Elide fp32 convert for const compares · 809f6b15
      martyn.capewell authored
      Reduce operations of the form f64cmp(fp32to64(x), k) to f32cmp(x, k) when k
      can be encoded as a 32-bit float.
      
      Review URL: https://codereview.chromium.org/1365623002
      
      Cr-Commit-Position: refs/heads/master@{#30909}
      809f6b15
  10. 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
  11. 21 Sep, 2015 1 commit
  12. 03 Sep, 2015 1 commit
  13. 24 Aug, 2015 1 commit
    • rmcilroy's avatar
      Add CompileInfo::GetDebugName() · 53ac9fe8
      rmcilroy authored
      Replaces all instances of the code which computed the debug
      name of a stub or function with calls to CompileInfo::GetDebugName instead.
      
      Also:
        - Removes useless parameter on CodeStub::GetMajorName
        - Removes FakeStubForTesting since it is no longer required
        - Adds CompileInfo::ShouldEnsureSpaceForLazyDeopt() to replace unclear calls to IsStub().
      
      Review URL: https://codereview.chromium.org/1297203002
      
      Cr-Commit-Position: refs/heads/master@{#30324}
      53ac9fe8
  14. 18 Aug, 2015 1 commit
    • danno's avatar
      [turbofan] Unify referencing of stack slots · cbbaf9ea
      danno authored
      Previously, it was not possible to specify StackSlotOperands for all
      slots in both the caller and callee stacks. Specifically, the region
      of the callee's stack including the saved return address, frame
      pointer, function pointer and context pointer could not be addressed
      by the register allocator/gap resolver.
      
      In preparation for better tail call support, which will use the gap
      resolver to reconcile outgoing parameters, this change makes it
      possible to address all slots on the stack, because slots in the
      previously inaccessible dead zone may become parameter slots for
      outgoing tail calls. All caller stack slots are accessible as they
      were before, with slot -1 corresponding to the last stack
      parameter. Stack slot indices >= 0 access the callee stack, with slot
      0 corresponding to the callee's saved return address, 1 corresponding
      to the saved frame pointer, 2 corresponding to the current function
      context, 3 corresponding to the frame marker/JSFunction, and slots 4
      and above corresponding to spill slots.
      
      The following changes were specifically	needed:
      
      * Frame	has been changed to explicitly manage three areas of the
        callee frame, the fixed header, the spill slot area, and the
        callee-saved register area.
      * Conversions from stack slot indices to fp offsets all now go through
        a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
      * The generation of deoptimization translation tables has been changed
        to support the new stack slot indexing scheme. Crankshaft, which
        doesn't support the new slot numbering in its register allocator,
        must adapt the indexes when creating translation tables.
      * Callee-saved parameters are now kept below spill slots, not above,
        to support saving only the optimal set of used registers, which is
        only known after register allocation is finished and spill slots
        have been allocated.
      
      Review URL: https://codereview.chromium.org/1261923007
      
      Cr-Commit-Position: refs/heads/master@{#30224}
      cbbaf9ea
  15. 17 Aug, 2015 1 commit
  16. 11 Aug, 2015 2 commits
  17. 10 Aug, 2015 1 commit
  18. 07 Aug, 2015 2 commits
  19. 31 Jul, 2015 1 commit
  20. 30 Jul, 2015 3 commits
  21. 23 Jul, 2015 1 commit
    • rmcilroy's avatar
      [interpreter] Add basic framework for bytecode handler code generation. · 7877c4e0
      rmcilroy authored
      Adds basic support for generation of interpreter bytecode handler code
      snippets. The InterpreterAssembler class exposes a set of low level,
      interpreter specific operations which can be used to build a Turbofan
      graph. The Interpreter class generates a bytecode handler snippet for
      each bytecode by assembling operations using an InterpreterAssembler.
      
      Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1239793002
      
      Cr-Commit-Position: refs/heads/master@{#29814}
      7877c4e0
  22. 13 Jul, 2015 2 commits
  23. 08 Jul, 2015 1 commit
  24. 02 Jul, 2015 1 commit
  25. 30 Jun, 2015 1 commit
  26. 26 Jun, 2015 1 commit
  27. 25 Jun, 2015 1 commit
  28. 17 Jun, 2015 1 commit
  29. 05 Jun, 2015 1 commit
  30. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1162993006
      
      Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  31. 03 Jun, 2015 1 commit
  32. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1131783003
      
      Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029