- 25 Apr, 2018 1 commit
-
-
Andreas Haas authored
I missed one required change which was hidden behind an #if. The fix is in the diff between Patch 1 and Patch 3. Original message: In this CL I remove the isolate from signatures of ExternalReference accessor functions where the isolate is not used. The uses of the isolate were already removed in previous CLs. Changes: * I split the ExternalReference list in external-reference.h into those which need the isolate for initialization and those which do not. * I removed the public constructors and replaced them by ExternalReference::Create(). The reason is to separate external creation more clearly from internal creation, because externally created ExternalReferences sometimes need redirection, whereas internally created ExternalReferences are just stored as they are. In addition, by removing the isolate from the signature of the public constructors, they suddenly exactly matched the interal constructor. * Replace all uses of the public constructors with ExternalReference::Create(). * Remove the isolate from all call sites where necessary. This is a step towards making WebAssembly compilation independent of the isolate. R=mstarzinger@chromium.org Bug: v8:7570 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057 Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52777}
-
- 24 Apr, 2018 3 commits
-
-
Andreas Haas authored
This reverts commit 44ea425a. Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575 Original change's description: > [refactoring] Remove the isolate from signatures of ExternalReferences > > In this CL I remove the isolate from signatures of ExternalReference > accessor functions where the isolate is not used. The uses of the > isolate were already removed in previous CLs. > > Changes: > * I split the ExternalReference list in external-reference.h into > those which need the isolate for initialization and those which do not. > > * I removed the public constructors and replaced them by > ExternalReference::Create(). The reason is to separate external > creation more clearly from internal creation, because externally > created ExternalReferences sometimes need redirection, whereas > internally created ExternalReferences are just stored as they are. > In addition, by removing the isolate from the signature of the > public constructors, they suddenly exactly matched the interal > constructor. > > * Replace all uses of the public constructors with > ExternalReference::Create(). > > * Remove the isolate from all call sites where necessary. > > > This is a step towards making WebAssembly compilation independent of > the isolate. > > Bug: v8:7570 > R=mstarzinger@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da > Reviewed-on: https://chromium-review.googlesource.com/1018982 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52768} TBR=mstarzinger@chromium.org,ahaas@chromium.org Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7570 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52769}
-
Andreas Haas authored
In this CL I remove the isolate from signatures of ExternalReference accessor functions where the isolate is not used. The uses of the isolate were already removed in previous CLs. Changes: * I split the ExternalReference list in external-reference.h into those which need the isolate for initialization and those which do not. * I removed the public constructors and replaced them by ExternalReference::Create(). The reason is to separate external creation more clearly from internal creation, because externally created ExternalReferences sometimes need redirection, whereas internally created ExternalReferences are just stored as they are. In addition, by removing the isolate from the signature of the public constructors, they suddenly exactly matched the interal constructor. * Replace all uses of the public constructors with ExternalReference::Create(). * Remove the isolate from all call sites where necessary. This is a step towards making WebAssembly compilation independent of the isolate. Bug: v8:7570 R=mstarzinger@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da Reviewed-on: https://chromium-review.googlesource.com/1018982 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52768}
-
Clemens Hammacher authored
Passing a pointer of the needed type, and then reading using ReadUnalignedValue is pointless, since the compiler can assume alignment of the pointer value. This CL fixes the remaining external refs of wasm to take an Address to a single buffer. R=ahaas@chromium.org Bug: v8:7570, v8:3770 Change-Id: If8a7324a4703e1e900cb3c5644baef207e6a371d Reviewed-on: https://chromium-review.googlesource.com/1023406 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52754}
-
- 20 Apr, 2018 2 commits
-
-
Clemens Hammacher authored
The convert operation only write an output value if the conversion succeeded. Thus, we always initialize the buffer before calling the conversion function. R=ahaas@chromium.org Change-Id: Ide230a1e608205f9067349db08adde6a90b31d6f Reviewed-on: https://chromium-review.googlesource.com/1021377 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52703}
-
Clemens Hammacher authored
Instead of passing multiple pointers to input and output, or to two input values, just pass one pointer which holds all inputs and where the output is written. This also reduces the size of generated Turbofan graphs, since only one stack slot is needed and less arguments are passed to the call. It also fixes undefined behaviour, since we were passing a pointer e.g. as {uint64_t*}, but accessed it using {ReadUnalignedValue}. Now we pass an Address, which does not have any alignment constraints. R=ahaas@chromium.org Bug: v8:3770, v8:6600 Change-Id: I54ef80b7e27f77587a9062560c0b3e01d6593e6d Reviewed-on: https://chromium-review.googlesource.com/1019147 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52702}
-
- 23 Feb, 2017 1 commit
-
-
Marja Hölttä authored
BUG=v8:5294 Change-Id: If45f25aae8de526027b7851cb4efe0ccf4a7c4b1 Reviewed-on: https://chromium-review.googlesource.com/444226 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43388}
-
- 20 Jul, 2016 1 commit
-
-
ahaas authored
This CL more or less reverts commit https://codereview.chromium.org/2107733002/ The use of the MathPow code stub that was introduced by that commit caused problems on arm64, and the MathPow code stub was also an obstacle in the implementation of parallel code generation. In addition this CL turns on the mjsunit/wasm/embenchen tests for arm64 which were turned off because of problems with MathPow on arm64. R=titzer@chromium.org, bradnelson@chromium.org Review-Url: https://codereview.chromium.org/2166793002 Cr-Commit-Position: refs/heads/master@{#37911}
-
- 21 Apr, 2016 1 commit
-
-
ahaas authored
This patch provides a new implementation of popcnt and ctz in the case where the platform does not provide these instructions. Instead of building a TF graph which implements it we now call a C function. Additionally I turned on additional tests in test-run-wasm-64.cc R=titzer@chromium.org Review URL: https://codereview.chromium.org/1857363003 Cr-Commit-Position: refs/heads/master@{#35685}
-
- 06 Apr, 2016 1 commit
-
-
ahaas authored
1) I moved the implementations of the wrapper functions into a new cc file so that I can use these wrapper functions in tests. 2) I made a generic test for all tests in test-run-calls-to-external-references.cc. In the new test we only compare the result of a function call through an external reference with the result of a direct function call. This is sufficient because we only want to test function calls through external references work here. The implementation of these functions are tested somewhere else. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1853123002 Cr-Commit-Position: refs/heads/master@{#35289}
-
- 15 Mar, 2016 1 commit
-
-
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}
-
- 14 Mar, 2016 1 commit
-
-
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}
-
- 07 Mar, 2016 1 commit
-
-
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}
-
- 04 Mar, 2016 1 commit
-
-
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}
-