1. 10 May, 2016 1 commit
  2. 09 May, 2016 1 commit
  3. 03 May, 2016 1 commit
  4. 29 Apr, 2016 1 commit
    • titzer's avatar
      [wasm] Binary 11: WASM AST is now postorder. · 2aa4656e
      titzer authored
      [wasm] Binary 11: br_table takes a value.
      [wasm] Binary 11: Add implicit blocks to if arms.
      [wasm] Binary 11: Add arities to call, return, and breaks
      [wasm] Binary 11: Add experimental version.
      
      This CL changes the encoder, decoder, and tests to use a postorder
      encoding of the AST, which is more efficient in decode time and
      space.
      
      R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
      BUG=chromium:575167
      LOG=Y
      
      Review-Url: https://codereview.chromium.org/1830663002
      Cr-Commit-Position: refs/heads/master@{#35896}
      2aa4656e
  5. 26 Apr, 2016 1 commit
  6. 15 Apr, 2016 2 commits
  7. 04 Apr, 2016 2 commits
    • titzer's avatar
      [turbofan] Handle dead diamonds in scheduling and add a test. · 45d75bca
      titzer authored
      The background here is that graphs generated from WASM are not trimmed.
      That means there can be some floating control diamonds that are not
      reachable from end. An assertion in the scheduler for phis from floating
      diamonds checks that the use edge in this situation is the control edge,
      but in general, any edge could cause this.
      
      Scheduling still works without this assertion. The longer term fix
      is to either trim the graphs (more compile time overhead for WASM)
      or improve the scheduler's handling of dead code in the graph. Currently
      it does not schedule dead code but the potential use positions of
      dead code are used in the computation of the common dominator of uses. We could
      recognize dead nodes in PrepareUses() and check in GetBlockForUse()
      as per TODO.
      
      R=bradnelson@chromium.org, mstarzinger@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1846933002
      
      Cr-Commit-Position: refs/heads/master@{#35245}
      45d75bca
    • ivica.bogosavljevic's avatar
      MIPS: Fix Run_Wasm_F32CopySign. · 114c109a
      ivica.bogosavljevic authored
      Run_Wasm_F32CopySign was failing because function copysign
      that is used to verify the results does implicit conversion
      from float to double. In this conversion we lose information
      about NaN sign and the test fails.
      
      Fix by using copysignf to avoid unnecessary float to double
      conversion.
      
      TEST=cctest/test-run-wasm/Run_Wasm_F32CopySign
      BUG=
      
      Review URL: https://codereview.chromium.org/1857753002
      
      Cr-Commit-Position: refs/heads/master@{#35237}
      114c109a
  8. 01 Apr, 2016 1 commit
  9. 31 Mar, 2016 2 commits
    • ahaas's avatar
      [wasm] Fixed float-to-int conversion tests. · ac7f0e2b
      ahaas authored
      *) For all tests the input validation was incorrect, i.e. some values
      were considered invalid although they were valid. The problem was that
      values which are outside int range can get in range through truncation.
      
      *) Removed an assertion in the x64 code generation of
      TruncateFloat64ToUint32 which trapped on negative inputs.
      
      *) Introduced a new TF operator TruncateFloat32ToUint32 which does
      the same as ChangeFloat32ToUint32 but does not trap on negative inputs.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1843983002
      
      Cr-Commit-Position: refs/heads/master@{#35176}
      ac7f0e2b
    • titzer's avatar
      [wasm] Fix and enable more tests. · 08e0ea38
      titzer authored
      R=ahaas@chromium.org, bradnelson@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1846613002
      
      Cr-Commit-Position: refs/heads/master@{#35156}
      08e0ea38
  10. 30 Mar, 2016 2 commits
  11. 29 Mar, 2016 1 commit
    • titzer's avatar
      [wasm] Fix arm64 frame alignment. · c9f59780
      titzer authored
          In JavaScript code and stubs, JSSP mirrors the CSP but may be unaligned.
          But in WASM code only CSP is used, like native code, and it must be
          aligned.
          Calls into WASM from JS need to carefully align the C stack
          pointer (csp) and restore the previous JSSP, while calls from WASM
          to JS need to compute a new JSSP and restore their CSP after the
          call.
      
      R=ahaas@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1811283003
      
      Cr-Commit-Position: refs/heads/master@{#35096}
      c9f59780
  12. 15 Mar, 2016 2 commits
    • ahaas's avatar
      [wasm] Int64Lowering of Word64Popcnt. · 2e6f3e86
      ahaas authored
      Word64Popcnt is lowered to Word32Popcnt(low-word) + Word32Popcnt(high_word).
      Since the optional Word64Popcnt operator does not exist on 32 bit platforms,
      I introduced a new operator "Word64PopcntPlaceholder" which is generated
      in the WasmCompiler and then lowered in the Int64Lowering.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1803453003
      
      Cr-Commit-Position: refs/heads/master@{#34777}
      2e6f3e86
    • ahaas's avatar
      [wasm] Int64Lowering of I64Div and I64Rem. · 29e0e8e9
      ahaas authored
      On 32-bit systems these 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 parameters is done in the
      Int64Lowering. We use the return value of the C function to determine
      whether the calculation should trap or not.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1804513002
      
      Cr-Commit-Position: refs/heads/master@{#34768}
      29e0e8e9
  13. 14 Mar, 2016 2 commits
    • titzer's avatar
      [wasm] Refactor tests for i64. · 4233050f
      titzer authored
      Move all tests that use i64 values into test-run-wasm-64.cc. Introduce
      macros that enable tests as they are implemented on 32 bit platforms.
      
      R=ahaas@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1784343004
      
      Cr-Commit-Position: refs/heads/master@{#34742}
      4233050f
    • 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
  14. 11 Mar, 2016 1 commit
  15. 09 Mar, 2016 1 commit
  16. 08 Mar, 2016 1 commit
    • binji's avatar
      [Wasm] Convert many of the fixed-size values to LEB128. · 78f6f838
      binji authored
      This CL modifies the following to be LEB128:
      * Function table indices
      * Import table signature indices
      * Export table function indices
      * Function signature param count
      * br/br_if break depth
      * br_table target count
      * block/loop expression count
      
      Still to do:
      * Import/export names (LEB128 count + inline data)
      * Data segments (LEB128 offset + size + inline data)
      * Function header stuff (should seperate into function sig and body sections)
      * Memory access alignment + offset (still discussing)
      
      BUG=
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1775873002
      
      Cr-Commit-Position: refs/heads/master@{#34603}
      78f6f838
  17. 07 Mar, 2016 2 commits
    • titzer's avatar
      [wasm] Rework encoding of local declarations. · 835c5e6b
      titzer authored
      Local declarations were previously encoded as an optional set of
      4 uint16 values as part of the function declaration. This CL
      implements the current design of moving these declarations to
      a list of pairs of (type, count) that is part of the body.
      
      R=bradnelson@chromium.org,binji@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1763433002
      
      Cr-Commit-Position: refs/heads/master@{#34564}
      835c5e6b
    • 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
  18. 04 Mar, 2016 5 commits
  19. 03 Mar, 2016 1 commit
  20. 27 Feb, 2016 1 commit
  21. 25 Feb, 2016 1 commit
    • ahaas's avatar
      [wasm] mips: Turn off signalling NaN tests on mips and mips64. · 5dc96ae2
      ahaas authored
      I turn the test off for now. The problem is that mips does not deal with
      signalling NaNs as expected.
      
      @v8-mips-ports: Could it be that the mips simulator deals differently
      with signalling NaNs than the actual hardware? The implementation that
      is tested in these tests assumes that sNaN * 1.0 = qNaN, where the bits
      of sNaN and qNaN are equal except for the most significant mantissa bit.
      This assumption holds for the simulator, but seems not to hold for actual
      mips hardware. Do you know more about that?
      
      R=mstarzinger@chromium.org, titzer@chromium.org, v8-mips-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1735673003
      
      Cr-Commit-Position: refs/heads/master@{#34278}
      5dc96ae2
  22. 23 Feb, 2016 1 commit
  23. 18 Feb, 2016 3 commits
  24. 12 Feb, 2016 1 commit
  25. 08 Feb, 2016 1 commit
  26. 05 Feb, 2016 2 commits