- 09 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
Change-Id: I2855af444db5dad910d99acc8179aef75e56d000 Bug: v8:9020 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559734Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60703}
-
- 08 Apr, 2019 1 commit
-
-
Pierre Langlois authored
We would only increment write barrier counters from the the MacroAssembler's RecordWrite method which is only used in limited cases. Instead, we should increment it inside the RecordWrite stub, this way we catch all uses, including WASM. Also, we had a static counter aimed at telling us how many barriers exist in generated code, as opposed to how many are executed. This counter was not functional since the compiler isn't aware of counters at the moment. Let's just remove it to avoid confusion. Change-Id: I6b173ab858c8984ef03ede225afdc999ba82b5c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524483Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#60673}
-
- 01 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
This is a reland of 6604f182 Original change's description: > [heap] Clean-up keys of oldspace weakmaps during scavenge > > This CL adds handling for cleaning up weakmap (EphemeronHashTable) > keys during scavenge, even if the weakmap resides in oldspace. > > Change-Id: If8d711c050ddbcae4dd6e8da549e0c0d08ba47b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523787 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60432} CQ_INCLUDE_TRYBOTS=luci.chrome.try:Mac Builder Perf Change-Id: Ie640f2b0340637a5391fb17ba3c9e6422eaf306a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541476 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#60554}
-
- 25 Mar, 2019 2 commits
-
-
Sigurd Schneider authored
This reverts commit 6604f182. Bug: chromium:945341 Original change's description: > [heap] Clean-up keys of oldspace weakmaps during scavenge > > This CL adds handling for cleaning up weakmap (EphemeronHashTable) > keys during scavenge, even if the weakmap resides in oldspace. > > Change-Id: If8d711c050ddbcae4dd6e8da549e0c0d08ba47b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523787 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60432} TBR=ulan@chromium.org,jarin@chromium.org,sigurds@chromium.org,leszeks@chromium.org Change-Id: I9dd9b11990a262a457fd1bedc2b45b4a786a81f7 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538133Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60447}
-
Sigurd Schneider authored
This CL adds handling for cleaning up weakmap (EphemeronHashTable) keys during scavenge, even if the weakmap resides in oldspace. Change-Id: If8d711c050ddbcae4dd6e8da549e0c0d08ba47b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523787 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#60432}
-
- 22 Mar, 2019 1 commit
-
-
Bill Budge authored
- Changes min and max sequences to propagate NaNs and signed zeroes. - Note that NaN propagation must preserve canonical NaNs. This is achieved by always returning canonical NaNs. This is also consistent with the WebAssembly scalar math spec. Bug: v8:8639 Change-Id: I04fdefabc54ea60f4d02e2081c32444a02dd6a83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524634 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#60414}
-
- 18 Mar, 2019 1 commit
-
-
Matheus Marchini authored
On LoadCodeObjectEntry check for IsOffHeapTrampoline instead of BuiltinIndexOffset so LoadCodeObjectEntry can correctly jump to the on-heap trampoline when we use --interpreted-frames-native-stack. R=jgruber@chromium.org, yangguo@google.com Bug: v8:8911 Change-Id: I172d4735671726d32328de246990b513106e3a7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1516692 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60288}
-
- 15 Mar, 2019 1 commit
-
-
Michael Starzinger authored
This slot has become obsolete now that all CEntry stubs are builtins (which are part of the rootset) and no longer need to be kept alive explicitly by a slot in the frame. R=verwaest@chromium.org BUG=v8:8834 Change-Id: I7b791cc509ef800bcf7aa5faab31ddf35370f944 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520725Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60267}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 08 Mar, 2019 2 commits
-
-
Pavel Medvedev authored
instead of forwarding template constructors for these classes introduced in edab9a20 commit. TurboAssemblerBase constructors were declared as public to make the inherited TurboAssembler, and MacroAssembler ctors also public. This fixes Visual C++ 2017 compile error, when the template ctor in TurboAssemblerBase class matches deleted copy ctor. Bug: v8:8935 Change-Id: I1144a7025830c3a0ab86acaa8ea81def02d293b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1496977Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60114}
-
Bill Budge authored
This is a reland of 821bc649 Original change's description: > [wasm simd] Fix F32x4 Min and Max > > - Fix F32x4 tests to save results in globals, so they can be checked > in C++ code. Perform correct checks in case of NaNs. > - Fix ia32, x64 implementations of F32x4Min, F32x4Max to correctly > deal with NaNs. > - Enable tests for all float values on all platforms, except skip > denormalized results on ARM, and skip extreme values for reciprocal, > reciprocal square root approximation opcodes. > - Disable Min, Max test for interpreter (see v8:8425) since it doesn't > handle NaNs correctly. > - Fix vmin, vmax implementations in ARM simulator. > > Bug: v8:8639 > Change-Id: I87e188e3cb078f09fdacfd9955f426c20a11bf64 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495897 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60021} Bug: v8:8639 Change-Id: Ic557aa1d323693eabf5885ff5eddc15e3174079b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1501279Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#60109}
-
- 05 Mar, 2019 2 commits
-
-
Pierre Langlois authored
The `TurboAssembler::CallRecordWriteStub()` method which generates out-of-line code to call the write barrier would push and pop arguments to move them to different registers. Let's use `mov` instructions instead, making sure we handle overlapping registers. Change-Id: Ideb654cd558e984ccb90c7cf44b1c2c49f1c5b50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499496 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#60026}
-
Deepti Gandluri authored
This reverts commit 821bc649. Reason for revert: Fails on ARM hardware :( https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/9271 Original change's description: > [wasm simd] Fix F32x4 Min and Max > > - Fix F32x4 tests to save results in globals, so they can be checked > in C++ code. Perform correct checks in case of NaNs. > - Fix ia32, x64 implementations of F32x4Min, F32x4Max to correctly > deal with NaNs. > - Enable tests for all float values on all platforms, except skip > denormalized results on ARM, and skip extreme values for reciprocal, > reciprocal square root approximation opcodes. > - Disable Min, Max test for interpreter (see v8:8425) since it doesn't > handle NaNs correctly. > - Fix vmin, vmax implementations in ARM simulator. > > Bug: v8:8639 > Change-Id: I87e188e3cb078f09fdacfd9955f426c20a11bf64 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495897 > Commit-Queue: Bill Budge <bbudge@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60021} TBR=bbudge@chromium.org,gdeepti@chromium.org Change-Id: Ib0dc8395ff86263fe0c02faa53d90c7da46b50a6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8639 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1501732Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#60022}
-
- 04 Mar, 2019 1 commit
-
-
Bill Budge authored
- Fix F32x4 tests to save results in globals, so they can be checked in C++ code. Perform correct checks in case of NaNs. - Fix ia32, x64 implementations of F32x4Min, F32x4Max to correctly deal with NaNs. - Enable tests for all float values on all platforms, except skip denormalized results on ARM, and skip extreme values for reciprocal, reciprocal square root approximation opcodes. - Disable Min, Max test for interpreter (see v8:8425) since it doesn't handle NaNs correctly. - Fix vmin, vmax implementations in ARM simulator. Bug: v8:8639 Change-Id: I87e188e3cb078f09fdacfd9955f426c20a11bf64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495897 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#60021}
-
- 26 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
Remove EmbeddedVector from utils.h Bug: v8:8834, v8:8912 Change-Id: I04e9f12121757bd0b87c68d7a4a5b213c2d8b686 Reviewed-on: https://chromium-review.googlesource.com/c/1486473Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59854}
-
- 25 Feb, 2019 1 commit
-
-
Benedikt Meurer authored
We'll need one bit in the SharedFunctionInfo::flags to record whether it's safe to skip arguments adaptor frames (for v8:8895), so this just removes the SharedFunctionInfo::IsDerivedConstructorBit which is redundant, since the same information is already available in the SharedFunctionInfo::FunctionKindBits, and most places in the code use that already, with the exception of the JSConstructStubGeneric builtin. This changes the JSConstructStubGeneric builtin to just check the function kind instead of testing the explicit bit, which also makes this more consistent. It seems like there's not much overhead to that, doing an additional bitmasking plus two comparisons instead of one. This shouldn't really matter since invocation and execution of the constructors is going to dominate and optimized code inlines all of this anyways. If this turns out to affect performance, we can still look into encoding the FunctionKindBits more cleverly. Drive-by-fix: Move the FunctionKindBits first in the flags to avoid the shift when accessing the function kind. This seems logic, since for the actual boolean bit fields it doesn't matter where they are in the flags, whereas for the function kind this saves one shift. Bug: v8:8834, v8:8895 Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306 Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59821}
-
- 21 Feb, 2019 1 commit
-
-
Benedikt Meurer authored
In the Crankshaft days we (mis)used the Representation to also express the various internal representations that the compiler understands. But with TurboFan we now have proper MachineRepresentation and MachineType, which do that independently. So there's no need to have this in the Representation class anymore, and instead the Representation class only needs to deal with the field representations. Bug: v8:8749, v8:8834, v8:8865 Change-Id: I34ea9558b5fdf20d6c7939b52762eaffd4316b06 Reviewed-on: https://chromium-review.googlesource.com/c/1479954 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59750}
-
- 15 Feb, 2019 1 commit
-
-
Jakob Kummerow authored
This takes heap-inl.h out of the "Giant Include Cluster". Naturally, that means adding a bunch of explicit includes in a bunch of places that relied on transitively including them before. As of this patch, no header file outside src/heap/ includes heap-inl.h. Bug: v8:8562,v8:8499 Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4 Reviewed-on: https://chromium-review.googlesource.com/c/1459659 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59617}
-
- 14 Feb, 2019 1 commit
-
-
Benedikt Meurer authored
When calling into API callbacks from TurboFan optimized, we can currently only take a fast-path when TurboFan is able to find some information about the receiver in the graph, or when the API callback specifies that it neither requires an access check (aka "accepts any receiver") nor an interface check (aka "compatible receiver check"). This change introduces a new CallFunctionTemplate builtin that sits in front of the CallApiCallback builtin and does both the access as well as the interface check as necessary (and raises appropriate exceptions). This way TurboFan can still call into the API callback via the fast-path even without ahead knowledge about the receiver, which is significantly faster than the generic call machinery for API callbacks. On the test case from the Angular team[1], the interesting metrics improve from DOM_mono: 0.273 ms DOM_mega: 0.571 ms DOM_call: 0.649 ms to DOM_mono: 0.264 ms DOM_mega: 0.572 ms DOM_call: 0.368 ms so the DOM_call is only about **1.4 times slower** than the DOM_mono and about **1.5 times faster** than the DOM_mega case (compared to **2.4 times slower**). Execution time in the DOM_call was reduced by around **~45%**. Currently this new code path is limited to TurboFan optimized code, but the idea is to eventually migrate the API calls from baseline to also use the new CSA functionality, but there are lot's of subleties to take into account, so starting with small changes to get coverage for the basic building blocks. [1]: https://mhevery.github.io/perf-tests/DOM-megamorphic.html Bug: v8:8820 Change-Id: Ie1029cf182ce05a6e519fd9a9d4fa825db8adb4c Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1470129 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59598}
-
- 13 Feb, 2019 2 commits
-
-
Nico Weber authored
For macros expanding to function definitions, I removed the spurious ; after macro invocations. For macros expandign to function declarations, I made the ; required and consistently inserted it. No behavior change. Bug: chromium:926235 Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549 Reviewed-on: https://chromium-review.googlesource.com/c/1467545Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59558}
-
Benedikt Meurer authored
Refactor the CallApiCallback builtin to - pass the context as with other stubs, and - pass holder and call data in registers. This avoids having to place holder and call data onto the stack, and thus makes it possible to easily call the CallApiCallback builtin from other builtins while just forwarding the (stack) arguments. The idea is to use this in the future to optimize the general case of calling into any API method via a FunctionTemplateInfo and doing appropriate security and/or interface checks upfront as necessary (eventually making the HandleApiCall C++ builtin obsolete at some point). Bug: v8:8820, chromium:913553 Change-Id: I10c0065016df4d0c24bac3d46945ea597b65ed02 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1469821 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59551}
-
- 07 Feb, 2019 2 commits
-
-
Sigurd Schneider authored
Drive-by: Refactor FlushInstructionCache to its own header. This removes dependencies of objects.cc and code.cc Bug: v8:8562 Change-Id: If23f3b9d4f2068e08c61c0f4b070ecfe1b9a6cc0 Reviewed-on: https://chromium-review.googlesource.com/c/1456081Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59435}
-
deepak1556 authored
When BUILDING_V8_SHARED in release builds __declspec(dllexport) causes generation of implicit constructors in the forwarding class while its deleted in TurboAssemblerBase, which leads to compilation errors like: In file included from gen/v8/v8_base_jumbo_6.cc:41: In file included from .\../../v8/src/interface-descriptors.cc:7: In file included from ../../v8\src/macro-assembler.h:40: ../../v8\src/x64/macro-assembler-x64.h(92,9): error: call to deleted constructor of 'v8::internal::TurboAssemblerBase' : TurboAssemblerBase(std::forward<Args>(args)...) {} ^ ~~~~~~~~~~~~~~~~~~~~~~~~ ../../v8\src/x64/macro-assembler-x64.h(536,25): note: in instantiation of function template specialization 'v8::internal::TurboAssembler::TurboAssembler<v8::internal::TurboAssembler>' requested here class V8_EXPORT_PRIVATE MacroAssembler : public TurboAssembler { ^ ../../v8\src/turbo-assembler.h(127,34): note: 'TurboAssemblerBase' has been explicitly marked deleted here DISALLOW_IMPLICIT_CONSTRUCTORS(TurboAssemblerBase); ^ 1 error generated. The original changes were made in https://chromium-review.googlesource.com/c/v8/v8/+/1414913 R=mstarzinger@chromium.org,jgruber@chromium.org,clemensh@chromium.org Bug: NONE Change-Id: I87a5a678b8bae13b3adc6f1c6ac0b9313ed18d85 Reviewed-on: https://chromium-review.googlesource.com/c/1454676 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59427}
-
- 06 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
This unifies the RelocInfo::Visit method across architectures. Bug: v8:8562 Change-Id: I36fdfb2f456aebb4d69977bb84727c9b49b22f69 Reviewed-on: https://chromium-review.googlesource.com/c/1456106 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59423}
-
- 05 Feb, 2019 1 commit
-
-
Junliang Yan authored
Change-Id: I59b14188682b5d8843a732aaebf1cc3a4403f7f8 Reviewed-on: https://chromium-review.googlesource.com/c/1454760Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59374}
-
- 01 Feb, 2019 1 commit
-
-
Jakob Gruber authored
This basically adjusts reality to match our expectations. Methods based on Code::kConstantPoolOffset expected the constant pool to be located immediately following the handler table and before the code comments section, while it was actually emitted before the jump table. We did not notice earlier since this is only relevant on ppc. Bug: v8:8758 Change-Id: I189af491fe133a7dc480ff4056372ba7a27faa81 Reviewed-on: https://chromium-review.googlesource.com/c/1445880 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59299}
-
- 30 Jan, 2019 1 commit
-
-
Jakob Gruber authored
This is an initial step towards clarifying the layout of the instruction area. As follow-ups, we should remove additional safepoint and handler table offset parameters, and perhaps alter Code::safepoint_table_offset (handler_table) semantics to always contain a real offset and avoid the magic 0 signifying nonexistent tables. Bug: v8:8758 Change-Id: I9f54629ff3ddad69904b0e1ce2a58e047397aa15 Reviewed-on: https://chromium-review.googlesource.com/c/1434036 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59202}
-
- 28 Jan, 2019 1 commit
-
-
Ulan Degenbaev authored
Change-Id: I927eed8354fdb3eba2d8ab94caafa89b1ce02016 Reviewed-on: https://chromium-review.googlesource.com/c/1436019 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#59115}
-
- 23 Jan, 2019 1 commit
-
-
Jakob Gruber authored
Code object iteration was missing logic for RELATIVE_CODE_TARGET reloc entries. Garbage collection could thus miss objects that were referenced only as targets of pc-relative calls or jumps. RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only at mksnapshot-time. This exposed another issue in that the interpreter entry trampoline copy we generate for profiling *did* contain relative calls in runtime-accessible code. This is a problem, since code space on arm is, by default, too large to be fully addressable through pc-relative calls. This CL thus also disables the related FLAG_interpreted_frames_native_stack feature on arm. Drive-by: Ensure the builtins constants table does not contain Code objects. Bug: v8:8713,v8:6666 Change-Id: Idd914b46970ad08f9091fc72113fa7aed2732e71 Reviewed-on: https://chromium-review.googlesource.com/c/1424866Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59023}
-
- 22 Jan, 2019 1 commit
-
-
Peter Marshall authored
Everything was including log.h through heap-inl.h, so remove that include by moving the one user into heap.cc, and then fix all the include errors. This reduces the log.h include ball from ~550 to ~100. Change-Id: I6d09bc2f365b48645fcfdc695a68ea12539a745d Reviewed-on: https://chromium-review.googlesource.com/c/1424198 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58981}
-
- 17 Jan, 2019 3 commits
-
-
Clemens Hammacher authored
Refactor all call sites to use the new API introduced in https://crrev.com/c/1411347 and remove the legacy constructors. R=mstarzinger@chromium.org Bug: v8:8689, v8:8562 Change-Id: Id73686413726b2860f551dd200ef4b8823ef3034 Reviewed-on: https://chromium-review.googlesource.com/c/1415491Reviewed-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@{#58884}
-
tzik authored
This updates the InterfaceDescriptor for JSRunMicrotasksEntry and RunMicrotasksTrampoline from DummyDescriptor to RunMicrotasksEntryDescriptor. Bug: v8:8124 Change-Id: I4522fd45bd18b33a2a4471b76c217d2a0f504cb0 Reviewed-on: https://chromium-review.googlesource.com/c/1412132 Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58879}
-
Clemens Hammacher authored
and TurboAssembler. Instead of listing all the different combinations of arguments (which is one more now, temporarily), just forward all arguments down via MacroAssembler and TurboAssembler to TurboAssemblerBase. Interestingly, this requires more specific types sometimes (int instead of size_t), since further down the forwarding chain, the compiler does not recognize any more that the value is a constant, and emits a warning about a possibly truncating implicit conversion. R=mstarzinger@chromium.org Bug: v8:8689, v8:8562 Change-Id: Ifd13d2210ee64251c0075c0d9b68cacd5107d9ab Reviewed-on: https://chromium-review.googlesource.com/c/1414913Reviewed-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@{#58869}
-
- 16 Jan, 2019 2 commits
-
-
Clemens Hammacher authored
When generating an Assembler, you currently have two choices: Either let the Assembler allocate a growable internal buffer, which is owned by the Assembler. Or provide an externally allocated buffer, which cannot grow. This CL changes this interface to allow providing any implementation of a buffer. The provided buffer can be a view to an externally owned buffer, which still can grow. This will be used to split WebAssembly compilation and code submission. The buffer needs to be able to grow, but cannot be owned by the Assembler because it has to survive until the code is submitted. R=mstarzinger@chromium.org Bug: v8:8689 Change-Id: Ib6c5ebffc8b71d0778944abac34f02c5cc7dbd79 Reviewed-on: https://chromium-review.googlesource.com/c/1411347 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58848}
-
Jakob Gruber authored
On ia32, arm and mips we generate miscellaneous memcpy-related functions at runtime: arm: memcpy for uint8-uint8 and uint16-uint8 {dest-source} pairs. ia32: memmove mips: memcpy uint8-uint8 In jitless mode, runtime codegen is disallowed, so these must be converted into builtins. As far as I can tell, the mips64 files were dead code (#ifdef'd to V8_HOST_ARCH_MIPS instead of MIPS64). Note also the slightly changed implementation of ia32's MemMove's jump tables. Bug: v8:8675 Change-Id: I5dc2a50fcbad332ce9f78228425b987b0d9acdf3 Reviewed-on: https://chromium-review.googlesource.com/c/1407067Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58839}
-
- 14 Jan, 2019 1 commit
-
-
Jakob Gruber authored
This code must move into builtins since --jitless disallows executable memory allocation at runtime. Removing CPU-dependent code will make that step easier. The hope is that processors have gotten better in the last couple of years and this code is unnecessary by now. Bug: v8:8675 Change-Id: I1f2f104befc5f65f1dd69e9643cc51290d2465b8 Reviewed-on: https://chromium-review.googlesource.com/c/1407061Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58770}
-
- 11 Jan, 2019 1 commit
-
-
Jakob Gruber authored
As far as I can tell these were unused; their only callers were arm and ppc simulators, but codegen explicitly returned nullptr if in a simulator build, falling back to std::sqrt. There's more potential cleanup to be done here for other functions defined in codegen-*.cc files. Tbr: clemensh@chromium.org Bug: v8:7777, v8:8675 Change-Id: I4b9d6062c6724a810ab094d09e3cd04a0b733d9b Reviewed-on: https://chromium-review.googlesource.com/c/1405851Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58740}
-
- 10 Jan, 2019 1 commit
-
-
tzik authored
This moves |root_register_value| parameter of JSEntryFunction to the first. I.e. the type of entry function will be changed from Object*(Object* new_target, Object* target, Object* receiver, int argc, Object*** args, Address root_register_value) to Object*(Address root_register_value, Object* new_target, Object* target, Object* receiver, int argc, Object*** args), and moves all parameter handling except for |root_register_value| from JSEntryVariant to JSEntryTrampolineHelper. This is a preparation to add another JS entry point for RunMicrotasks, whose type will be Object*(Address root_register_value, MicrotaskQueue*). The new entry point requires |root_register_value| to be the first to share the implementation of the EntryFrame setup with existing ones. Bug: v8:8124 Change-Id: I675376a2ccd240f61cf04eea6fe9a91031e06ede Reviewed-on: https://chromium-review.googlesource.com/c/1372857 Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58683}
-
- 08 Jan, 2019 2 commits
-
-
Ross McIlroy authored
Remove the use of a jump table in the prologue of the deopt entries and instead pass the bailout id explicitly in a register when calling the deopt entry routine from optimized code. This unifies the logic with the way the Arm64 code works. It saves the following amount of memory in code stubs: - arm: 384KB - ia32: 480KB - x64: 240KB This could be offset by a slight increase in the size of optimized code for loading the immediate, however this impact should be minimal and will scale with the maximum number of bailout ids (e.g., the size of code will increase by one instruction per bailout id on Arm, therefore ~98,000 bailouts will be needed before the overhead is greater than the current fixed table size). Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25 Reviewed-on: https://chromium-review.googlesource.com/c/1398224 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#58636}
-
Jakob Kummerow authored
The two names refer to the same thing by now, so this patch is entirely mechanical. Bug: v8:3770 Change-Id: Ia360c06c89af6b3da27fd21bbcaeb2bdaa28ce22 Reviewed-on: https://chromium-review.googlesource.com/c/1397705Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58615}
-