1. 15 May, 2018 1 commit
  2. 17 Apr, 2018 1 commit
  3. 14 Mar, 2018 1 commit
  4. 13 Feb, 2018 1 commit
  5. 09 Feb, 2018 1 commit
  6. 16 Jan, 2018 1 commit
  7. 08 Jan, 2018 1 commit
    • Clemens Hammacher's avatar
      [simulator] Make Call variadic · a3baa353
      Clemens Hammacher authored
      In order to remove the CALL_GENERATED_CODE macro, it helps a lot to
      unify the interfaces of the simulators and make the Call method variadic
      in the number of arguments.
      This CL does that for each simulator. A follow-up CL will then
      completely remove the CALL_GENERATED_CODE macro and replace uses with
      the (new) GeneratedCode wrapper.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7182
      Change-Id: I1f81445ec2faba30f0bd233b022ae1f0fae4e96f
      Reviewed-on: https://chromium-review.googlesource.com/850873
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50413}
      a3baa353
  8. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored
      This patch normalizes the casing of hexadecimal digits in escape
      sequences of the form `\xNN` and integer literals of the form
      `0xNNNN`.
      
      Previously, the V8 code base used an inconsistent mixture of uppercase
      and lowercase.
      
      Google’s C++ style guide uses uppercase in its examples:
      https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
      
      Moreover, uppercase letters more clearly stand out from the lowercase
      `x` (or `u`) characters at the start, as well as lowercase letters
      elsewhere in strings.
      
      BUG=v8:7109
      TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
      NOPRESUBMIT=true
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
      Reviewed-on: https://chromium-review.googlesource.com/804294
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  9. 01 Dec, 2017 2 commits
  10. 07 Nov, 2017 1 commit
  11. 20 Oct, 2017 1 commit
    • Clemens Hammacher's avatar
      Reland "[test] Add nan bit patterns to uint{32,64}_vector" · bd19ea4a
      Clemens Hammacher authored
      This is a reland of 6f93d59d.
      One more test had to be disabled (tracked by bug 6954), and
      two machops tests needed to be changed to use boxed floats
      and doubles.
      
      Original change's description:
      > [test] Add nan bit patterns to uint{32,64}_vector
      > 
      > If you just cast those patterns to float or double and pass them
      > around, the quiet/signaling NaN bit might change. We had several bugs
      > around this, so add these patterns to the general input vectors.
      > 
      > This uncovers a bug in the wasm interpreter, which will be fixed in a
      > separate CL.
      > 
      > R=ahaas@chromium.org
      > 
      > Bug: v8:6947, v8:6954
      > Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
      > Reviewed-on: https://chromium-review.googlesource.com/725345
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48731}
      
      Bug: v8:6947, v8:6954
      Change-Id: I9a38b5d9324131c3950c537910371a73c93d2c13
      Reviewed-on: https://chromium-review.googlesource.com/728439Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48780}
      bd19ea4a
  12. 19 Oct, 2017 1 commit
  13. 13 Oct, 2017 1 commit
  14. 28 Sep, 2017 1 commit
    • Enrico Bacis's avatar
      [wasm] Introduce the WasmContext · 6cd7a5a7
      Enrico Bacis authored
      The WasmContext struct introduced in this CL is used to store the
      mem_size and mem_start address of the wasm memory. These variables can
      be accessed at C++ level at graph build time (e.g., initialized during
      instance building). When the GrowMemory runtime is invoked, the context
      variables can be changed in the WasmContext at C++ level so that the
      generated code will load the correct values.
      
      This requires to insert a relocatable pointer only in the
      JSToWasmWrapper (and in the other wasm entry points), the value is then
      passed from function to function as an automatically added additional
      parameter. The WasmContext is then dropped when creating an Interpreter
      Entry or when invoking a JavaScript function. This removes the need of
      patching the generated code at runtime (i.e., when the memory grows)
      with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
      However, we still need to patch the code at instance build time to patch
      the JSToWasmWrappers; in fact the address of the WasmContext is not
      known during compilation, but only when the instance is built.
      
      The WasmContext address is passed as the first parameter. This has the
      advantage of not having to move the WasmContext around if the function
      does not use many registers. This CL also changes the wasm calling
      convention so that the first parameter register is different from the
      return value register. The WasmContext is attached to every
      WasmMemoryObject, to share the same context with multiple instances
      sharing the same memory. Moreover, the nodes representing the
      WasmContext variables are cached in the SSA environment, similarly to
      other local variables that might change during execution.  The nodes are
      created when initializing the SSA environment and refreshed every time a
      grow_memory or a function call happens, so that we are sure that they
      always represent the correct mem_size and mem_start variables.
      
      This CL also removes the WasmMemorySize runtime (since it's now possible
      to directly retrieve mem_size from the context) and simplifies the
      GrowMemory runtime (since every instance now has a memory_object).
      
      R=ahaas@chromium.org,clemensh@chromium.org
      CC=gdeepti@chromium.org
      
      Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
      Reviewed-on: https://chromium-review.googlesource.com/671008
      Commit-Queue: Enrico Bacis <enricobacis@google.com>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48209}
      6cd7a5a7
  15. 14 Aug, 2017 1 commit
  16. 01 Aug, 2017 1 commit
  17. 06 Jul, 2017 1 commit
  18. 18 May, 2017 1 commit
  19. 16 May, 2017 1 commit
  20. 09 May, 2017 2 commits
  21. 21 Apr, 2017 1 commit
  22. 13 Apr, 2017 1 commit
  23. 20 Mar, 2017 1 commit
    • ahaas's avatar
      [arm64] The ubfx instruction can be used with a mask-width=64 · 086ec2bd
      ahaas authored
      The code-generator used i.InputInt6 to get the mask-width from the
      instruction. However, thereby 64 got wrapped to 0, which is an invalid
      mask width. I changed the i.InputInt6 to an i.InputInt32, which should
      be okay because the mask-width comes from base::bits::CountPopulation64.
      
      BUG=v8:6122
      R=bmeurer@chromium.org, v8-arm-ports@googlegroups.com
      
      Review-Url: https://codereview.chromium.org/2755373002
      Cr-Commit-Position: refs/heads/master@{#43927}
      086ec2bd
  24. 07 Mar, 2017 1 commit
  25. 02 Mar, 2017 1 commit
    • ahaas's avatar
      [arm64][turbofan] Tst instructions can have a shifted operand. · 91cd0707
      ahaas authored
      This CL fixes a bug in the implementation of the code generation of
      kArm64Tst32, where the shift input operand of kArm64Tst32 was ignored.
      Please take a special look at the fix in kArm64Tst. I applied the fix
      there as well, but because of differences in the instruction selector
      I was not able to write a test for it.
      
      R=v8-arm-ports@googlegroups.com
      BUG=v8:6028
      
      Review-Url: https://codereview.chromium.org/2729853003
      Cr-Commit-Position: refs/heads/master@{#43555}
      91cd0707
  26. 23 Feb, 2017 1 commit
  27. 14 Feb, 2017 1 commit
  28. 10 Feb, 2017 2 commits
  29. 08 Feb, 2017 1 commit
    • ahaas's avatar
      [arm64][turbofan] Fix add+shr for big shift values. · ed6e28d2
      ahaas authored
      Arm64 compiles "x +_64 (y >> shift)" into a single instruction if
      "shift" is a constant. The code generator expects that "shift" is a
      32 bit constant. however, TurboFan can also pass in a 64 bit constant,
      which caused a crash in the code generator.
      
      With this CL we cast the constant of TurboFan to an int in the
      instruction selector and thereby satisfy the assumption of the code
      generator. This should be correct since the code generator anyways cast
      the "shift" to an int5 or int6 eventually.
      
      R=v8-arm-ports@googlegroups.com
      BUG=v8:5923
      
      Review-Url: https://codereview.chromium.org/2669203005
      Cr-Commit-Position: refs/heads/master@{#43036}
      ed6e28d2
  30. 06 Dec, 2016 1 commit
  31. 11 Nov, 2016 1 commit
  32. 10 Nov, 2016 1 commit
  33. 19 Oct, 2016 1 commit
  34. 22 Aug, 2016 1 commit
  35. 05 Aug, 2016 1 commit
  36. 29 Jul, 2016 1 commit
  37. 22 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Change Float64Max/Float64Min to JavaScript semantics. · ba092fb0
      bmeurer authored
      So far we don't have a useful way to inline Math.max or Math.min in
      TurboFan optimized code. This adds new operators NumberMax and NumberMin
      and changes the Float64Max/Float64Min operators to have JavaScript
      semantics instead of the C++ semantics that it had previously.
      
      This also removes support for recognizing the tenary case in the
      CommonOperatorReducer, since that doesn't seem to have any positive
      impact (and actually doesn't show up in regular JavaScript, where
      people use Math.max/Math.min instead).
      
      Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2170343002
      Cr-Commit-Position: refs/heads/master@{#37971}
      ba092fb0