- 08 Aug, 2017 25 commits
-
-
Aseem Garg authored
This reverts commit 649b1e70. Reason for revert: A1 Jetstream bots are still failing. Original change's description: > [wasm] Reland "[wasm] redirect wasm calls to js functions through a GCed table" > > This reverts commit 25f03308. > > Reason for revert: Fix the cause of bot failure and reland > > Original change's description: > > Revert "[wasm] redirect wasm calls to js functions through a GCed table" > > > > This reverts commit eb65f35e. > > > > Reason for revert: Broke jetstream benchmark on android. > > > > BUG=chromium:750828 > > > > Original change's description: > > > [wasm] redirect wasm calls to js functions through a GCed table > > > > > > With this patch, rather than embedding the JSReceiver address directly > > > in the WasmToJS wrappers, we put that in a fixed array with global handle > > > scope and instead embed the location of the handle and the index in the > > > wrapper. This ensures that the wrapper doesn't need to be patched if the > > > GC kicks in. This is needed to get the WASM code off the GCed heap. > > > > > > R=mtrofin@chromium.org > > > > > > Bug: > > > Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d > > > Reviewed-on: https://chromium-review.googlesource.com/581682 > > > Commit-Queue: Aseem Garg <aseemgarg@chromium.org> > > > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#46884} > > > > TBR=mtrofin@chromium.org,aseemgarg@google.com,aseemgarg@chromium.org,clemensh@chromium.org > > > > # Not skipping CQ checks because original CL landed > 1 day ago. > > > > Change-Id: I26f49ee0a1fe73cc5d8852ded87b56638be39ebf > > Reviewed-on: https://chromium-review.googlesource.com/596268 > > Commit-Queue: Aseem Garg <aseemgarg@chromium.org> > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#47059} > > R=mtrofin@chromium.org,aseemgarg@google.com,aseemgarg@chromium.org,clemensh@chromium.org,sullivan@chromium.org > > Change-Id: I29ef35f6e612a706d9f571da3e7beb1da8b5052b > Bug: chromium:750828 > Reviewed-on: https://chromium-review.googlesource.com/597010 > Commit-Queue: Aseem Garg <aseemgarg@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47177} TBR=bradnelson@chromium.org,sullivan@chromium.org,mtrofin@chromium.org,aseemgarg@google.com,aseemgarg@chromium.org,clemensh@chromium.org Bug: chromium:750828 Change-Id: I04b12c0eb0705ad809822a7d7461423be77d942a Reviewed-on: https://chromium-review.googlesource.com/606867 Commit-Queue: Aseem Garg <aseemgarg@chromium.org> Reviewed-by:
Aseem Garg <aseemgarg@chromium.org> Cr-Commit-Position: refs/heads/master@{#47231}
-
Anisha Rohra authored
Port ee350c31 R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com BUG= LOG=N Change-Id: I2dfc7562fc327a4d8577c405d5fec8c440ef0a49 Reviewed-on: https://chromium-review.googlesource.com/606707Reviewed-by:
Jaideep Bajwa <bjaideep@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47230}
-
Mircea Trofin authored
This CL consolidates ownership of parameters used to compile code (which we always specialize) in 2 places: - ModuleEnv for compile-time data - WasmCompiledModule for runtime data The parameters in question are: memory size and start; globals start; address of indirect function tables (and their signatures, respectively); and address to be used for wasm call sites. Ideally, we'd collapse this down to one place, however, we need specialization data to survive serialization. We can achieve this we get off the GC heap and use a different wasm code serializer. The CL: - removes aliasing of parts of the specialization data, and moves to using ModuleEnv as a token of passing around compile-time data, instead of a mixture of ModuleEnv, WasmInstance, and some other structures. ModuleEnv is responsible for providing a consistent view of the specialization data, e.g. valid memory sizes (multiples of page size), and matching sized function tables and signatures. - removes WasmInstance, as its data is now contained by ModuleEnv. - removes ModuleBytesEnv. We now pass the wire bytes explicitly. They can't always be assumed as present (e.g. streaming compilation), and probably more refactoring may need to happen once streaming compilation lands and we better understand our dependencies. Change-Id: Id7e6f2cf29e51b5756eee8b6f8827fb1f375e5c3 Reviewed-on: https://chromium-review.googlesource.com/592531 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47229}
-
jing.bao authored
Reconstruct pshufb using macro Bug: Change-Id: I5556ce1108378fc7a7658443cd09c3f676c16aa7 Reviewed-on: https://chromium-review.googlesource.com/603907Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#47228}
-
Clemens Hammacher authored
We are only calling {checkAvailable} with uint32_t, thus the type received should also be uint32_t. This also gives better error messages for integers >kMaxInt. R=titzer@chromium.org Change-Id: I40655b80dcc601e05fbb0c92cedba72ca806e2b3 Reviewed-on: https://chromium-review.googlesource.com/605893 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Ivica Bogosavljevic authored
Add support for the simulation of MIPS SIMD MI10 instruction group, which included Load Vector and Store Vector instructions. Add corresponding test for these instructions. Bug: Change-Id: I7cbc9d8dff2a779d9a716f539cd9a2bbb8ac694a Reviewed-on: https://chromium-review.googlesource.com/595567Reviewed-by:
Miran Karić <Miran.Karic@imgtec.com> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Cr-Commit-Position: refs/heads/master@{#47226}
-
Adam Klein authored
Change-Id: I3f150ef3424cb28c89db6ef8fcb1a3340a8ff8b1 Reviewed-on: https://chromium-review.googlesource.com/604725Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47225}
-
Caitlin Potter authored
A spec change (https://github.com/tc39/proposal-async-iteration/commit/a0dfeba1a8029012b6e964099929b8a157818c9f) introduced a number of Await operations to the spec. In turn, this caused generated bytecode for async generators to grow drastically. This commit moves the Await within AsyncGeneratorYield (https://tc39.github.io/proposal-async-iteration/#sec-asyncgeneratoryield step 5) into a new TFJ builtin, similar in structure to AsyncGeneratorAwait, but instead of resuming the generator on resolution of the Promise, the current generator request's Promise is fulfilled instead. This results in a reduction in generated bytecode without losing any statically available information. BUG=v8:5855 Change-Id: Ib5bcf06132d221beffdea30639a7b4437030143b Reviewed-on: https://chromium-review.googlesource.com/582487 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47224}
-
Yang Guo authored
R=jgruber@chromium.org Change-Id: I67b296c97091b4bfa3864f5187cf3e7e4d452961 Reviewed-on: https://chromium-review.googlesource.com/604800Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Ie964f001792e2be9647bfd32722071dd343755d2 Reviewed-on: https://chromium-review.googlesource.com/605688Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47222}
-
Ulan Degenbaev authored
This patch removes creation of fillers in the middle of a large page and fixes assert in Heap::NotifyObjectLayoutChange. The fillers in large pages are useless since we do not sweep large object space. Bug: chromium:752426 Change-Id: I01c230223f28d6d54b7362ee70e9d83de50678fd Reviewed-on: https://chromium-review.googlesource.com/601994 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47221}
-
Michael Starzinger authored
R=jarin@chromium.org Change-Id: I336595bdcbdb41d7c33aa138fdc7893aa02e655b Reviewed-on: https://chromium-review.googlesource.com/605647Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47220}
-
Jakob Gruber authored
This moves deserializer setup boilerplate inside the deserializers, and makes improper usage less likely. For instance: ObjectDeserializer deserializer(&scd); /* ... deserializer setup ... */ MaybeHandle<HeapObject> obj = deserializer.Deserialize(isolate); /* ... result checks and casts ... */ has now become: /* All setup and casts inside deserializer, impossible to illegally use the same instance multiple times. */ MaybeHandle<SharedFunctionInfo> maybe_result = ObjectDeserializer::DeserializeSharedFunctionInfo( isolate, &scd, source); Bug: v8:6624 Change-Id: Id5a1848e024e89cf86e5292389ba7c89f31d8e6b Reviewed-on: https://chromium-review.googlesource.com/604791 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47219}
-
Michael Starzinger authored
This avoid introduction of {TypeGuard} nodes during load elimination. Such type guard could lead to contradicting type information where a constant {NumberConstant} node was guarded to have {ExternalPointer} type, which would lead to an impossible constraint on representation selection. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-752826 BUG=chromium:752826 Change-Id: Ida3815af24ccc8a48474b8d66117b9718f61adda Reviewed-on: https://chromium-review.googlesource.com/605547Reviewed-by: -
Clemens Hammacher authored
This removes the last instance where we did manually what {LowerInt64} already does. R=titzer@chromium.org Change-Id: I5e0de0f8ed1ae31f295e947a9fe36e4142200b65 Reviewed-on: https://chromium-review.googlesource.com/602238Reviewed-by: -
Michael Starzinger authored
This makes sure we perform a proper holder lookup when trying to inline API accessors calls in TurboFan. Inlining is completely disabled in case the holder is not found, otherwise the appropriate holder is passed via the {PropertyAccessInfo} structure (if different from the receiver). R=bmeurer@chromium.org TEST=cctest/test-api/ReceiverSignature BUG=chromium:752149 Change-Id: I7b192724afd99d651b6477b2f2c8b403a10efb9d Reviewed-on: https://chromium-review.googlesource.com/603615 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: -
Ben L. Titzer authored
R=cbruni@chromium.org Bug: Change-Id: Id1993e64375084e43479c20607a5c20778117ecc Reviewed-on: https://chromium-review.googlesource.com/601910Reviewed-by:
-
Tobias Tebbi authored
This is a reland of a6c3f143 Original change's description: > [turbofan] enable new implementation of escape analysis > > Bug: > Change-Id: I0218ab67bf391deb8f1b1b78811643eb84745b7c > Reviewed-on: https://chromium-review.googlesource.com/595508 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47032} Change-Id: I8efc9676088508c0102c70785b546d80d9c4036c Reviewed-on: https://chromium-review.googlesource.com/603788Reviewed-by:
-
Clemens Hammacher authored
Revert "Partial revert of "Remove ~MaybeHandle and statically assert that handles are trivially copyable"" This reverts commit 1dfaec26. Reason for revert: Does not fix the performance regression, see bug. Original change's description: > Partial revert of "Remove ~MaybeHandle and statically assert that handles are trivially copyable" > > Reason: cause Blink regression on Android > > Original CL: https://chromium-review.googlesource.com/c/538463/ > > Bug: chromium:735910 > Change-Id: I405e71f6ffeaf9fa467036a6fafa0271a60de9d3 > Reviewed-on: https://chromium-review.googlesource.com/593247 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Loo Rong Jie <loorongjie@gmail.com> > Cr-Commit-Position: refs/heads/master@{#46995} R=yangguo@chromium.org,loorongjie@gmail.com,jbroman@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:735910 Change-Id: I65eecd575fb1b77471c6dd83a01df6c4e8a85214 Reviewed-on: https://chromium-review.googlesource.com/603797Reviewed-by:
-
Tobias Tebbi authored
Adding the missing test for https://chromium-review.googlesource.com/c/603717. Bug: chromium:752722 Change-Id: I8a4ca161b691532e481ebe9f7d05c306beb4c90a Reviewed-on: https://chromium-review.googlesource.com/604792Reviewed-by:
-
Jakob Gruber authored
Another pure refactoring CL. This extracts methods used only by Deserializer subclasses. Bug: v8:6624 Change-Id: Ib4dd7cdc591dff217e282e68a490c8c7129b9c96 Reviewed-on: https://chromium-review.googlesource.com/602188 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
Change the CALL_IC machinery inside of Ignition to collect new.target feedback for Construct and ConstructWithSpread bytecodes instead of collecting feedback about the target, and adapt TurboFan's JSCallReducer to consume feedback for new.target instead of target on JSConstruct nodes. This enables TurboFan to inline JSCreate - and thus the actual instance allocation - into derived leaf constructors even if the leaf constructor itself is not inlined, and thereby removes this weird performance cliff. The feedback for target in case of class constructors is provided by the function context specialization, and in case of `new A`, we can just use the feedback for new.target, as both target and new.target are A in that case. Bug: v8:5517, v8:6399, v8:6679 Change-Id: I0475e2500e787fd672ed037ac0faed78a8fa5dc0 Reviewed-on: https://chromium-review.googlesource.com/604790Reviewed-by:
-
Benedikt Meurer authored
Bug: v8:6679 Change-Id: I1fff8ffa037629636f31ecd2b731f5b9de89ce44 Reviewed-on: https://chromium-review.googlesource.com/604789Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/181c098..411d3b5 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/1fec0c8..98218d1 Rolling v8/tools/swarming_client: https://chromium.googlesource.com/external/swarming.client/+log/a56c2b3..42721e1 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I3d2d98ec9abd9d813986d3d82c010c8b0d46fa67 Reviewed-on: https://chromium-review.googlesource.com/604549Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#47208}
-
Adam Klein authored
This code appears to have been wrong forever, as it only threw in strict mode (presumably predating ES2015 const). In order to get exactly the right behavior, special handling of sloppy named function expressions is required. Rather than polluting PropertyAttributes with another dummy value, this CL simply adds a bool output argument to Context::Lookup to indicate that case. Bug: v8:6677 Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b Reviewed-on: https://chromium-review.googlesource.com/602690Reviewed-by:
-
- 07 Aug, 2017 15 commits
-
-
Benedikt Meurer authored
The ConstructFunctionForwardVarargs and ConstructForwardVarargs builtins, which are used when inlining the Reflect.construct builtin into TurboFan optimized code, didn't properly check the new.target parameter whether it's a constructor. Bug: chromium:752481 Change-Id: I9b8f8c429d6eaed0ff8d27fc3f6b52eb906766a2 Reviewed-on: https://chromium-review.googlesource.com/604187 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47206}
-
Mircea Trofin authored
This is part of the effort to consolidate the ownership of wasm instantiation/specialization parameters. This change is focused solely on the interpreter part of that effort, to verify we're not regressing performance in interpreter benchmarks. There are two aspects being addressed: - dataflow-wise, we always fetch the interpreter's memory view from the runtime objects (i.e. WasmInstanceObject/WasmCompiledModule). This is consistent with how other instance-specific information is obtained (e.g. code, indirect functions). - representation-wise, we do not reuse ModuleEnv/WasmInstance just for the memory view, because it is surprising that other instance info isn't accessed from there. Bug: Change-Id: I536fbffd8e1f142a315fa1770ba9b08319f56a8e Reviewed-on: https://chromium-review.googlesource.com/602083Reviewed-by:
-
Tobias Tebbi authored
The code accidentally jumped over the actual left-shift part when the head of the array was the hole. Bug: chromium:752722 Change-Id: I300a3ebcfafb07d6ecebc01fa57c66eb26f349ac Reviewed-on: https://chromium-review.googlesource.com/603717Reviewed-by:
-
Tobias Tebbi authored
Bug: chromium:752438 Change-Id: I6e168f0e8101cf9f28915ca94c40d408ed75d079 Reviewed-on: https://chromium-review.googlesource.com/603612 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Alexandre Talon authored
Currently only A test operators had output, but since ABReducer and BCReducer perform in-place replacement of A nodes into B nodes, and then sometimes into C nodes, we need B and C nodes to have as many outputs. Otherwise, we run into a situation where a node {x} has a use {y}, but its operators has 0 outputs, which is inconsistent. Bug: Change-Id: I0f73b83d2115dfeda3c9cbc97b9a2fc168f4c31b Reviewed-on: https://chromium-review.googlesource.com/603716Reviewed-by: -
Ulan Degenbaev authored
Bug: chromium:752750 TBR: mlippautz@chromium.org Change-Id: I95ca30742c05be03dcaebb0cd32af04b226e23e2 Reviewed-on: https://chromium-review.googlesource.com/603652Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47201}
-
Maya Lekova authored
This reverts commit 15ef03cb. Reason for revert: Found the following bugs Bug: chromium:752846, chromium:752712, chromium:752850 Original change's description: > Reland "[builtins] Port getting property from Proxy to CSA" > > This reland is after fix in [heap] Delete wrong DCHECK. > It includes moving ProxyGetProperty to its own stub to reduce > binary size. > > This is a reland of 47a97aa5 > Original change's description: > > [builtins] Port getting property from Proxy to CSA > > > > Bug: v8:6559, v8:6557 > > Change-Id: If6c51f5483adb73ddd2495cede5d85e887a3c298 > > Reviewed-on: https://chromium-review.googlesource.com/589212 > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > > Commit-Queue: Maya Lekova <mslekova@google.com> > > Cr-Commit-Position: refs/heads/master@{#47113} > > Bug: v8:6559, v8:6557 > Change-Id: I76acd97ba1acb62b7e7983db1741441d997050f0 > Reviewed-on: https://chromium-review.googlesource.com/600215 > Commit-Queue: Maya Lekova <mslekova@google.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Franziska Hinkelmann <franzih@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47159} TBR=jkummerow@chromium.org,mstarzinger@chromium.org,franzih@chromium.org,jgruber@chromium.org,ishell@chromium.org,bmeurer@chromium.org,mslekova@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: I51bef25a031b02cf4deab11282473acae57f1ed3 Reviewed-on: https://chromium-review.googlesource.com/603708 Commit-Queue: Maya Lekova <mslekova@google.com> Reviewed-by:
-
Ross McIlroy authored
Refactors CompileUnoptimizedCode to do all the finalization for both inner and the outermost function after having prepared and executed their compile jobs. This will enable the function to be split into an off-thread phase and a finalization main thread phase. BUG=v8:5203 Change-Id: I400933c27b7aa52f9a7318b721adecfc94c80981 Reviewed-on: https://chromium-review.googlesource.com/602236 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Ross McIlroy authored
Moves creation of the CompilationInfo for unoptimized compilation into the respective CompilationJobs for Igntition, Fullcode and asm.js. This unifies the behaviour with respect to the optimized compilation jobs, and enables the CompileInfo to be owned by the CompilationJob. As part of this change, we no longer build new dummy ParseInfos for eager inner functions, instead using just the single outer ParseInfo created during the actual parsing. BUG=v8:5203 Change-Id: I6813758dfc5eeff44f5a40bf621184e330593bf9 Reviewed-on: https://chromium-review.googlesource.com/601990 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Yang Guo authored
R=jgruber@chromium.org Change-Id: Iad6f815d2476c59a498b7f580ec664417e83c675 Reviewed-on: https://chromium-review.googlesource.com/600050 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
Drop the deprecated CallConstructStub and remove the use of CallICStub from fullcodegen, since that feedback is unused completely every since Crankshaft got removed, thus we can safely unlink all the CallIC stuff from fullcodegen nowadays, and completely nuke the CallICStub and the CallICTrampolineStub now (we can also transitively nuke the unused CreateAllocationSiteStub and CreateWeakCellStub). Instead the CallIC logic is integrated into Ignition now, and part of the bytecode handlers for [[Call]] and [[Construct]]. There's still some follow-up cleanup with the way the Array constructor feedback is integrated, but that's way easier now. Bug: v8:5517, v8:6399, v8:6409, v8:6679 Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619 Reviewed-on: https://chromium-review.googlesource.com/603609 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
The interpreter was not able to call imported wasm functions (hitting UNIMPLEMENTED). This CL fixes this by creating a "CWasmEntry", which is signature-specific. It has JS linkage and receives the wasm code object to call and a buffer containing all arguments (similar to the interpreter entry). It loads all arguments from the buffer and calls the given code object. The c-wasm-entry code objects are cached per instance, such that we only create them once per signature. These wasm entry stubs will also allow us to call back to compiled code from the interpreter, which we might want to do to reduce the slowdown of executing wasm for debugging. R=titzer@chromium.org Bug: chromium:735792 Change-Id: I7fecec3a7bec62a9de40fff115b684759b12a28b Reviewed-on: https://chromium-review.googlesource.com/600308 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
As of https://chromium-review.googlesource.com/600968 the CallIC no longer supports AllocationSite feedback for [[Call]], so we can drop the TurboFan bits that deal with AllocationSites for JSCall nodes as well. This further simplifies the handling of the Array constructor. Drive-by-fix: Rename Builtins::kArrayCode to Builtins::kArrayConstructor for sake of consistency. Bug: v8:6399 Change-Id: I9e6a684fc00dd72e25f925db5f407c3f3f715873 Reviewed-on: https://chromium-review.googlesource.com/602354 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This reverts commit 6c541561. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/17240 Original change's description: > [ic] Properly integrate the CallIC into Ignition. > > Drop the deprecated CallConstructStub and remove the use of CallICStub > from fullcodegen, since that feedback is unused completely every since > Crankshaft got removed, thus we can safely unlink all the CallIC stuff > from fullcodegen nowadays, and completely nuke the CallICStub and the > CallICTrampolineStub now (we can also transitively nuke the unused > CreateAllocationSiteStub and CreateWeakCellStub). > > Instead the CallIC logic is integrated into Ignition now, and part of > the bytecode handlers for [[Call]] and [[Construct]]. There's still some > follow-up cleanup with the way the Array constructor feedback is > integrated, but that's way easier now. > > Bug: v8:5517, v8:6399, v8:6409, v8:6679 > Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835 > Reviewed-on: https://chromium-review.googlesource.com/602134 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47192} TBR=rmcilroy@chromium.org,yangguo@chromium.org,bmeurer@chromium.org Change-Id: I416ce6646f62ceb4127b3acee43912ee0d701c23 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5517, v8:6399, v8:6409, v8:6679 Reviewed-on: https://chromium-review.googlesource.com/603647Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47193}
-
Benedikt Meurer authored
Drop the deprecated CallConstructStub and remove the use of CallICStub from fullcodegen, since that feedback is unused completely every since Crankshaft got removed, thus we can safely unlink all the CallIC stuff from fullcodegen nowadays, and completely nuke the CallICStub and the CallICTrampolineStub now (we can also transitively nuke the unused CreateAllocationSiteStub and CreateWeakCellStub). Instead the CallIC logic is integrated into Ignition now, and part of the bytecode handlers for [[Call]] and [[Construct]]. There's still some follow-up cleanup with the way the Array constructor feedback is integrated, but that's way easier now. Bug: v8:5517, v8:6399, v8:6409, v8:6679 Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835 Reviewed-on: https://chromium-review.googlesource.com/602134 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
