- 21 Feb, 2020 1 commit
-
-
Mike Stanton authored
Relanding the Fast C API code with fix for UBSan undefined behavior issue. Design doc: http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/ This CL implements basic API with integer and pointer types marshaling. What is not supported yet: - sequences - annotations - floating point arguments - 64-bit arguments - exception handling - InstanceOf checks for the pointer types - functions with non-void return type Bug: chromium:1052746 TBR=yangguo@chromium.org,mvstanton@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org,mslekova@chromium.org Change-Id: Ifca9de3156cf18c9dac0d14c19f8d6a7004cad83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066971Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#66391}
-
- 19 Feb, 2020 2 commits
-
-
Shu-yu Guo authored
This reverts commit 4e11ad92. Reason for revert: Signed int overflow in TestFastApiCalls in UBSan https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/9976 Original change's description: > [turbofan] Fast API calls from TurboFan > > Relanding the Fast C API code with fix for arm sim lite build. > > Design doc: > http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/ > > This CL implements basic API with integer and pointer types marshaling. > > What is not supported yet: > - sequences > - annotations > - floating point arguments > - 64-bit arguments > - exception handling > - InstanceOf checks for the pointer types > - functions with non-void return type > > Bug: chromium:1052746 > > TBR=yangguo@chromium.org,mvstanton@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org > > Change-Id: I4421ce817e3b6159a38d2cb39fb97847f128e648 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064223 > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66344} TBR=mvstanton@chromium.org Change-Id: I63bde3e0b7f92506fd8ec6d39683524bc9811aa6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1052746 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062739Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66347}
-
Mike Stanton authored
Relanding the Fast C API code with fix for arm sim lite build. Design doc: http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/ This CL implements basic API with integer and pointer types marshaling. What is not supported yet: - sequences - annotations - floating point arguments - 64-bit arguments - exception handling - InstanceOf checks for the pointer types - functions with non-void return type Bug: chromium:1052746 TBR=yangguo@chromium.org,mvstanton@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org Change-Id: I4421ce817e3b6159a38d2cb39fb97847f128e648 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064223Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#66344}
-
- 18 Feb, 2020 2 commits
-
-
Shu-yu Guo authored
This reverts commit 50790c0b. Reason for revert: Arm sim compile breakage: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/8657 Original change's description: > [turbofan] Fast API calls from TurboFan > > Design doc: > http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/ > > This CL implements basic API with integer and pointer types marshaling. > > What is not supported yet: > - sequences > - annotations > - floating point arguments > - 64-bit arguments > - exception handling > - InstanceOf checks for the pointer types > - functions with non-void return type > > Bug: chromium:1052746 > > Change-Id: Idbbf6dd50f43dfc9f8d707fe3333e5da3da84a13 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030740 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66322} TBR=yangguo@chromium.org,mvstanton@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org Change-Id: Id4301f46618d92fc1f65f1db8e1961793a91a09c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1052746 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062570Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66323}
-
Maya Lekova authored
Design doc: http://doc/1SAHn7d8M7CoazTd1laVF8gduFC_ikZWiYuytrR9c4Oc/ This CL implements basic API with integer and pointer types marshaling. What is not supported yet: - sequences - annotations - floating point arguments - 64-bit arguments - exception handling - InstanceOf checks for the pointer types - functions with non-void return type Bug: chromium:1052746 Change-Id: Idbbf6dd50f43dfc9f8d707fe3333e5da3da84a13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030740 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#66322}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 28 Oct, 2019 1 commit
-
-
Michael Starzinger authored
R=jgruber@chromium.org BUG=v8:6666,v8:9810 Change-Id: I972983d8e86729843f4a1bbe050e3b37a3c0c61c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881147Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64578}
-
- 25 Oct, 2019 1 commit
-
-
Michael Starzinger authored
R=miladfar@ca.ibm.com Change-Id: I42963b089243c45a3d065fb00e2864500bd33afb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879934Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64563}
-
- 23 Oct, 2019 2 commits
-
-
Michael Starzinger authored
This changes the way {SaveFPRegsMode} is stored in a {CallDescriptor}. The value is now encoded in the flags field, similar to all other boolean properties. It removes the last mutable field from the call descriptor, making the struct fully immutable. R=neis@chromium.org Change-Id: I6bca118c7ce0c5bc77e7aa2fcc6541439bd27b3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868616 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64512}
-
Michael Starzinger authored
R=neis@chromium.org,miladfar@ca.ibm.com BUG=v8:9872 Change-Id: Ia8b0da9a6026f7933503ecd9e735d7fc3fdff364 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869190Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64507}
-
- 17 Oct, 2019 1 commit
-
-
Milad Farazmand authored
The calling conventions on AIX uses function descriptors, which means that pointers to functions do not point to code, but instead point to metadata about them. When calling JITed code, we must assure to use function descriptors instead of raw pointers when needed. Before this CL 213504b9, all CallCFunction on AIX were guaranteed to have function descriptors. Starting form the CL mentioned above, CallCFunction can also Jump to a Trampoline which does not have a function descriptor, hence a new "CallCFunctionWithoutFunctionDescriptor" method is proposed to deal with this issue. BUG= v8:9766 Change-Id: I9343c31c812f5d4dda8503a5adf024b24dbde072 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825961 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64357}
-
- 21 Aug, 2019 2 commits
-
-
Andreas Haas authored
The LinkageLocation currently consists of two fields, a bit_field and a machine_type. The existing equality check only checked the equality of the bit_field, which meant that a FP register location and a GP register location could alias. I added a static {IsSameLocation} function which checks that not just the bit_field but also if one of the two locations at least has a subtype of the other. Note that we do not check for type-equality because {CanTailCall} checks, which are the main user of the LinkageLocation equality check, should pass even if the result types are in a sub-typing relationship. R=mstarzinger@chromium.org Bug: v8:9396 Change-Id: Iaa2d11311d0c18e8ffc1dd934e369106ab2456a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763533 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63319}
-
Andreas Haas authored
The linkage should not have any knowledge about the existance of nodes. R=mstarzinger@chromium.org Bug: v8:9396 Change-Id: If10bf113c6ec19c434573a8d9bb7b736caef5dee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763532 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63313}
-
- 05 Aug, 2019 1 commit
-
-
Clemens Hammacher authored
Instead of exposing a {kNext} constant to be used to construct the next bitfield, expose a templatized {Next} type alias. This ensures that the storage type is the same for all bitfields created this way. It's also shorter. Apart from the expected changes in the code base, the AST node classes are changed to expose a {NextBitField} templated type alias instead of a {kNextBitFieldIndex} constant. They thus follow the same pattern as {BitField} itself. R=jkummerow@chromium.org, mstarzinger@chromium.org, verwaest@chromium.org Bug: v8:9396 Change-Id: I70a1b0bd71cde694ec53444de0ca55e4cf0a3836 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728615Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63068}
-
- 01 Aug, 2019 1 commit
-
-
Michael Starzinger authored
This removes the explicit {kCallWithCallerSavedRegisters} opcode which is just a regular call node with special handling for saving/restoring caller saved registers before/after the call. This is now handled via the {CallDescriptor::kCallerSavedRegisters} flag. R=neis@chromium.org BUG=v8:9396 Change-Id: Ie6421085eb2be8a067040222cd5215a9b1013048 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728611Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63021}
-
- 29 Jul, 2019 3 commits
-
-
Clemens Hammacher authored
This is a reland of 658ff200 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} Bug: v8:9396, v8:7629 Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62959}
-
Clemens Hammacher authored
This reverts commit 658ff200. Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} TBR=yangguo@chromium.org,clemensh@chromium.org Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396, v8:7629 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62958}
-
Clemens Hammacher authored
We have hundreds of classes that derive from {BitField} without adding any functionality. This CL switches all such occurrences to 'using' declarations instead. Before: class MyBitField : public BitField<int, 6, 4, MyEnum> {}; After: using MyBitField = BitField<int, 6, 4, MyEnum>; This might reduce compilation time by reducing the number of existing classes. The old pattern is forbidden now by making {BitField} final. R=yangguo@chromium.org Bug: v8:9396, v8:7629 Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62956}
-
- 27 Jun, 2019 1 commit
-
-
Jakob Kummerow authored
powered by a new function Execution::CallWasm and a corresponding, Turbofan-generated CWasmEntry stub. This entirely sidesteps the traditional Execution::Invoke -> JSEntryStub path. Change-Id: If2b97825cca4ce927eecbddc248c64782d903287 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660618 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62424}
-
- 29 May, 2019 1 commit
-
-
Jakob Kummerow authored
So far, calls to Wasm C/C++ API functions reused the call descriptors of WasmImportWrappers, and the stack frame type of regular Wasm functions. This CL cleans that up by introducing separate implementations for both. No change in functionality or performance is expected. Change-Id: I79301fa81da52283cc776ddf19d4712372f3a58b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632235 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61914}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 29 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
Even though both are allowed in the style guide, it recommends to use 'using', as its syntax is more consistent with the rest of C++. This CL turns all typedefs in compiler code to 'using' declarations. R=mstarzinger@chromium.org Bug: v8:8834 Change-Id: I3baf3ecbfe2c853cb17bb479ebbf140382193b5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545896 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60527}
-
- 28 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The workaround is simple: cast to unsigned before shifting. Bug: v8:3770 Change-Id: I5f0f7af697ec5db0ab1df3d061008940c83c5c56 Reviewed-on: https://chromium-review.googlesource.com/c/1436215Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#59140}
-
- 25 Jan, 2019 1 commit
-
-
Andreas Haas authored
Anyref parameters can exist across GC runs. Therefore the GC has to know where anyref parameters are on the stack so that it can mark them in its marking phase, and update them in the compaction phase. Already in a previous CL we grouped all anyref parameters so that they can be found more easily in a stack frame, see https://crrev.com/c/1371827. In this CL we implement the stack scanning itself. Note that anyref parameters are not scanned while iterating over the caller's frame (to which they actually belong), but while iterating over the callee's frame. The reason is that with tail-calls, only the callee knows how many tagged stack parameters (aka anyref parameters) there are. R=mstarzinger@chromium.org also-by=mstarzinger@chromium.org Bug: v8:7581 Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7 Reviewed-on: https://chromium-review.googlesource.com/c/1424955 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59099}
-
- 19 Dec, 2018 2 commits
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: I0dab49a03b74abc68600885f4951c5cb727a3d73 Reviewed-on: https://chromium-review.googlesource.com/c/1366736Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58364}
-
Sigurd Schneider authored
This refactoring reduces the LoC after preprocessor expansion by 370,322 gen ( 21 files): 71,503 to 1,631,168 ( 23x) src ( 624 files): 367,639 to 53,231,764 ( 145x) test ( 392 files): 490,770 to 37,450,839 ( 76x) third_party ( 432 files): 239,085 to 9,547,902 ( 40x) total ( 1521 files): 1,183,681 to 102,836,194 ( 87x) gen ( 21 files): 71,503 to 1,613,222 ( 23x) src ( 624 files): 367,634 to 52,964,046 ( 144x) test ( 392 files): 490,771 to 37,366,181 ( 76x) third_party ( 432 files): 239,085 to 9,547,902 ( 40x) total ( 1521 files): 1,183,677 to 102,465,872 ( 87x) Bug: v8:8562 Change-Id: Ib4e771c37471a2ff19c5538e62c038943cc74eaf Reviewed-on: https://chromium-review.googlesource.com/c/1382469Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58349}
-
- 17 Dec, 2018 2 commits
-
-
Jakob Gruber authored
The kCallOnHeapBuiltin name has gotten very confusing now that builtins are actually off the heap (and the generated code will directly call off-heap). Bug: v8:7777 Change-Id: Ie14069eee2fc11ef9aec64868c50832f6138ae8f Reviewed-on: https://chromium-review.googlesource.com/c/1379883Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58291}
-
Jakob Gruber authored
Currently, Torque's builtin pointers store a Code target underneath and callsites generate a kArchCallCodeObject opcode. When embedded builtins are enabled, the call thus first calls the on-heap trampoline, which finally jumps to the target off-heap builtin code. This will no longer be possible in jitless mode, since on-heap code must not be executable. As a step towards changing the way builtin pointers are called (function pointers will hold the builtin index as a Smi, and callsites look up the off-heap target address and jump there), this CL adds a dedicated opcode for builtin pointer calls to the compiler pipeline. The calling mechanism itself is unchanged, changes there will happen in a follow-up. Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'. Bug: v8:7777 Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58281}
-
- 19 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
Instead, include macro-assembler.h (and others) where needed. R=mstarzinger@chromium.org Bug: v8:8238, v8:7490 Change-Id: I6ba4420bafee3d937bc6b648ac907f30a1d6aa52 Reviewed-on: https://chromium-review.googlesource.com/c/1340280Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57599}
-
- 18 Oct, 2018 1 commit
-
-
Sigurd Schneider authored
This is necessary for the arguments adaptor, as there are only 5 gp registers available and a call to the arguments adaptor trampoline that does not have the trampoline address as a immediate needs 6 (4 arguments + esi as context + register to call through). Bug: v8:6666 Change-Id: Ie96cf0352c323e07e0daf369953df8f4ee9acb81 Reviewed-on: https://chromium-review.googlesource.com/c/1283050 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56767}
-
- 10 Oct, 2018 1 commit
-
-
Ben L. Titzer authored
This CL refactors the implementation of WASM->JS import wrappers in order to make the wrapper code shareable. Instead of specializing to the import index, we use a tuple as the object ref in the both the import and indirect tables. The tuple allows the wrapper code to load both the calling instance and the target callable, rather than relying on code specialization. This requires some tricky codegen machinery, because WASM call descriptors expect an instance argument in a given register, yet the wrappers receive a tuple, the code generator must generate a prologue that loads the instance (and the callable), since it is not possible to express this at the graph level. R=mstarzinger@chromium.org CC=clemensh@chromium.org Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6 Reviewed-on: https://chromium-review.googlesource.com/c/1268237 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#56520}
-
- 22 Jun, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:7754 Change-Id: I6e1461d5e4214b5649f850166c3a988019098465 Reviewed-on: https://chromium-review.googlesource.com/1110126 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53958}
-
- 21 Jun, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:7754, v8:6600 Change-Id: I4db943d4a4a02a14bba670f89661ea98c5e306dd Reviewed-on: https://chromium-review.googlesource.com/1107919 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53907}
-
- 18 Jun, 2018 2 commits
-
-
Clemens Hammacher authored
Currently each isolate stores its own array of {CallInterfaceDescriptorData}. This array has size 173, and each entry has 40 bytes. That's already 7kB per isolate. Additionally, each {CallInterfaceDescriptorData} allocates two heap-allocated arrays, which probably add up to more than the static size of the {CallInterfaceDescriptorData}. Note that all the {CallInterfaceDescriptorData} instances are initialized eagerly on isolate creation. Since {CallInterfaceDescriptor} is totally isolate independent itself, this CL refactors the current design to avoid a copy of them per isolate, and instead shares them process-wide. Still, we need to free the allocated heap arrays when the last isolate dies to avoid leaks. This can probably be refactored later by statically initializing more and avoiding the heap allocations all together. This refactoring will also allow us to use {CallInterfaceDescriptor}s from wasm background compilation threads, which are not bound to any isolate. R=mstarzinger@chromium.org, titzer@chromium.org Bug: v8:6600 Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494 Reviewed-on: https://chromium-review.googlesource.com/1100879 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#53803}
-
Michael Starzinger authored
R=ishell@chromium.org Change-Id: I84288cc16297dbe33adddbdf08b689db95d0fc04 Reviewed-on: https://chromium-review.googlesource.com/1104164Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53786}
-
- 14 Jun, 2018 2 commits
-
-
Michael Starzinger authored
This allows WebAssembly runtime stubs implemented as {WasmCode} to be called with regular stub linkage. So far we have only been able to call such stubs with WebAssembly linkage. Also switch two more on-heap builtins over to WebAssembly runtime stubs. R=clemensh@chromium.org BUG=v8:7424 Change-Id: Ifa553b5908ee27a1be780c325a114449d7fe7001 Reviewed-on: https://chromium-review.googlesource.com/1100882Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53734}
-
Igor Sheludko authored
Bug: v8:5269 Change-Id: I78678aee42b2ae930b995cd194b4d20516e0d229 Reviewed-on: https://chromium-review.googlesource.com/1098929 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53730}
-
- 07 May, 2018 1 commit
-
-
jgruber authored
Stubs and builtins are very similar. The main differences are that stubs can be parameterized and may be generated at runtime, whereas builtins are generated at mksnapshot-time and shipped with the snapshot (or embedded into the binary). My main motivation for these conversions is that we can generate faster calls and jumps to (embedded) builtins callees from (embedded) builtin callers. Instead of going through the builtins constants table indirection, we can simply do a pc-relative call/jump. This also unlocks other refactorings, e.g. removal of CallRuntimeDelayed. TBR=mlippautz@chromium.org Bug: v8:6666 Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53027}
-
- 03 May, 2018 1 commit
-
-
Marja Hölttä authored
Restores some sensemaking properties, such as making src/machine-type.h (lower level header) independent of src/zone/zone.h (higher level header). BUG=v8:7490 Change-Id: Ibc6e5c7a75e4aaf917d086cf70267abc7ee9a9b0 Reviewed-on: https://chromium-review.googlesource.com/1039586Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#52941}
-