1. 15 Mar, 2016 3 commits
  2. 14 Mar, 2016 3 commits
    • ahaas's avatar
      [wasm] Fixed register allocation for Word32PairShl on arm. · 2ddfe43a
      ahaas authored
      The previous register allocation allowed invalid register aliasing in
      cases where in the TF graph the node was used for multiple inputs of the
      Word32PairShl node.
      
      Additionally I renamed PairLsl to LslPair in the code generation for
      consistency.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1776393004
      
      Cr-Commit-Position: refs/heads/master@{#34755}
      2ddfe43a
    • ahaas's avatar
      [wasm] Int64Lowering of Int64Add on ia32 and arm. · 1b230799
      ahaas authored
      Int64Add is lowered to a new turbofan operator, Int32AddPair. The new
      operator takes 4 inputs an generates 2 outputs. The inputs are the low
      word of the left input, high word of the left input, the low word of the
      right input, and high word of the right input. The ouputs are the low
      and high word of the result of the addition.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1778493004
      
      Cr-Commit-Position: refs/heads/master@{#34747}
      1b230799
    • ahaas's avatar
      [wasm] Int64Lowering of I64XConvertFXX instructions. · d57d14b9
      ahaas authored
      On 32-bit systems I64XConvertFXX instructions are compiled to calls to
      C functions. The TF node for the function call is already generated in
      the wasm compiler, the lowering of the I64 parameter is done in the
      Int64Lowering. We use the return value of the C function to determine
      whether the conversion should trap or not.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1775903002
      
      Cr-Commit-Position: refs/heads/master@{#34738}
      d57d14b9
  3. 10 Mar, 2016 1 commit
  4. 08 Mar, 2016 2 commits
  5. 07 Mar, 2016 1 commit
    • ahaas's avatar
      x87: fix the use of CheckFloatEq and CheckDoubleEq in test. · a5d41888
      ahaas authored
      Instead of using CheckFloatEq and CheckDoubleEq directly, I introduced
      a macro which first stores the expected result in a volatile variable.
      
      Here are some comments of previous CLs:
      
      The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
      
        Here is the key comments from CL #31808
        Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
        those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
        The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
        The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
      
        So we add the following sentence to do type cast to keep the same precision for RunCallInt64ToFloat32/RunCallInt64ToFloat64. Such as: volatile double expect = static_cast<float>(*i).
      
      R=titzer@chromium.org, weiliang.lin@intel.com
      
      Review URL: https://codereview.chromium.org/1773513002
      
      Cr-Commit-Position: refs/heads/master@{#34534}
      a5d41888
  6. 04 Mar, 2016 2 commits
    • ahaas's avatar
      [wasm] Int64Lowering of FXXXConvertI64 instructions. · b1e34590
      ahaas authored
      On 32-bit systems FXXXConvertI64 instructions are compiled to calls to
      C functions. The TF node for the function call is already generated in
      the wasm compiler, the lowering of the I64 parameter is done in the
      Int64Lowering.
      
      R=titzer@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1738623003
      
      Cr-Commit-Position: refs/heads/master@{#34487}
      b1e34590
    • bmeurer's avatar
      [compiler] Introduce code stubs for string relational comparisons. · 5912e0f0
      bmeurer authored
      Add StringLessThanStub, StringLessThanOrEqualStub, StringGreaterThanStub
      and StringGreaterThanOrEqualStub, based on the CodeStubAssembler, and
      hook them up with TurboFan (and Ignition). The stubs are currently
      essentially comparable with the StringCompareStub, which is now
      obsolete. We can later extend these stubs to cover more interesting
      cases (i.e. two byte sequential string comparisons, etc.).
      
      R=epertoso@chromium.org
      
      Review URL: https://codereview.chromium.org/1765823002
      
      Cr-Commit-Position: refs/heads/master@{#34485}
      5912e0f0
  7. 03 Mar, 2016 1 commit
    • bmeurer's avatar
      [compiler] Introduce StringEqualStub and StringNotEqualStub. · 2689548e
      bmeurer authored
      These new stubs perform exactly the same job as the string equality case
      for the CompareIC, but are platform independent and usable outside of
      fullcodegen and Crankshaft. We use them in the StrictEqualStub and the
      StrictNotEqualStub instead of falling back to the runtime immediately
      for String comparisons, and we also use them in TurboFan to perform
      String equality or inequality comparisons.
      
      These stubs currently handle only internalized and one byte strings w/o
      going to C++, but it should be easy to add support for more string cases
      later, i.e. utilizing already flattened cons strings or comparing two
      byte strings as well.
      
      Review URL: https://codereview.chromium.org/1761823002
      
      Cr-Commit-Position: refs/heads/master@{#34459}
      2689548e
  8. 02 Mar, 2016 1 commit
  9. 01 Mar, 2016 1 commit
  10. 26 Feb, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Bailout if LoadBuffer typing assumption doesn't hold. · 58ab990a
      bmeurer authored
      The LoadBuffer operator that is used for asm.js heap access claims to
      return only the appropriate typed array type, but out of bounds access
      could make it return undefined. So far we tried to "repair" the graph
      later if we see that our assumption was wrong, and for various reasons
      that worked for some time. But now that wrong type information that is
      propagated earlier is picked up appropriately and thus we generate wrong
      code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
      thus get 2147483648 instead of 0 (with proper JS truncation).
      
      This was always considered a temporary hack until we have a proper
      asm.js pipeline, but since we still run asm.js through the generic
      JavaScript pipeline, we have to address this now. Quickfix is to just
      bailout from the pipeline when we see that the LoadBuffer type was
      wrong, i.e. the result of LoadBuffer is not properly truncated and thus
      undefined or NaN would be observable.
      
      R=mstarzinger@chromium.org, jarin@chromium.org
      BUG=chromium:589792
      LOG=y
      
      Review URL: https://codereview.chromium.org/1740123002
      
      Cr-Commit-Position: refs/heads/master@{#34322}
      58ab990a
  11. 25 Feb, 2016 1 commit
  12. 24 Feb, 2016 2 commits
    • mythria's avatar
      Revert of [Interpreter] Implements calls through CallICStub in the... · eb358178
      mythria authored
      Revert of [Interpreter] Implements calls through CallICStub in the interpreter. (patchset #15 id:270001 of https://codereview.chromium.org/1688283003/ )
      
      Reason for revert:
      It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code  related to the type feedback vector into the builtin.
      
      Original issue's description:
      > [Interpreter] Implements calls through CallICStub in the interpreter.
      >
      > Calls are implemented through CallICStub to collect type feedback. Adds
      > a new builtin called InterpreterPushArgsAndCallIC that pushes the
      > arguments onto stack and calls CallICStub.
      >
      > Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
      > go through CallICStub.
      >
      > MIPS port contributed by balazs.kilvady.
      >
      > BUG=v8:4280, v8:4680
      > LOG=N
      >
      > Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
      > Cr-Commit-Position: refs/heads/master@{#34244}
      
      TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280, v8:4680
      
      Review URL: https://codereview.chromium.org/1731253003
      
      Cr-Commit-Position: refs/heads/master@{#34252}
      eb358178
    • mythria's avatar
      [Interpreter] Implements calls through CallICStub in the interpreter. · 20362a22
      mythria authored
      Calls are implemented through CallICStub to collect type feedback. Adds
      a new builtin called InterpreterPushArgsAndCallIC that pushes the
      arguments onto stack and calls CallICStub.
      
      Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
      go through CallICStub.
      
      MIPS port contributed by balazs.kilvady.
      
      BUG=v8:4280, v8:4680
      LOG=N
      
      Review URL: https://codereview.chromium.org/1688283003
      
      Cr-Commit-Position: refs/heads/master@{#34244}
      20362a22
  13. 23 Feb, 2016 1 commit
    • zhengxing.li's avatar
      X87: Change the test case for X87 RunRoundUint32ToFloat32. · 2cd94856
      zhengxing.li authored
        The CL #33796 (https://codereview.chromium.org/1628133002) added the RunRoundUint32ToFloat32 test case and X87 failed at it.
      
        The reason is same as the CL #33630 (Issue 1649323002: X87: Change the test case for X87 RunRoundInt32ToFloat32), please refer: https://codereview.chromium.org/1649323002.
      
        Here is the key comments from CL #33630:
        Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
        those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
        The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
        The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
      
        For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case
        fail.
      
        So we add the following sentence to do type case to keep the same precision for RunRoundUint32ToFloat32. Such as: volatile double expect = static_cast<float>(*i).
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1714413002
      
      Cr-Commit-Position: refs/heads/master@{#34202}
      2cd94856
  14. 19 Feb, 2016 2 commits
  15. 18 Feb, 2016 2 commits
  16. 16 Feb, 2016 5 commits
  17. 15 Feb, 2016 2 commits
  18. 12 Feb, 2016 4 commits
  19. 10 Feb, 2016 2 commits
  20. 09 Feb, 2016 1 commit
    • bmeurer's avatar
      [intrinsics] Kill the %_IsMinusZero intrinsic. · 00f7d1f5
      bmeurer authored
      By now only the default %TypedArray%.prototype.sort compare function
      and the JS implementation of SameValueZero were still using the odd
      %_IsMinusZero intrinsic, whose semantics both included a number check
      (actually HeapNumber test) plus testing if the heap number stores the
      special -0 value. In both cases we already know that we deal with
      number so we can reduce it to a simple number test for -0, which can
      be expressed via dividing 1 by that value and checking the sign of
      the result. In case of the compare function, we can be even smarter
      and work with the reciprocal values in case x and y are equal to 0
      (although long term we should probably rewrite the fast case for
      the typed array sorting function in C++ anyway, which will be way,
      way faster than our handwritten callback-style, type-feedback
      polluted JS implementation).
      
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1680783002
      
      Cr-Commit-Position: refs/heads/master@{#33833}
      00f7d1f5
  21. 08 Feb, 2016 1 commit
  22. 06 Feb, 2016 1 commit