- 22 Nov, 2021 1 commit
-
-
Maya Lekova authored
This is a reland of b9ddcbc8 The original CL was reverted due to an MSAN issue, that is fixed by moving the signature mapping onto the Isolate (instead of having per-thread storage, which got invalid on multithreaded compilation). This CL also contains fixes for the Bazel config and for a data race when obtaining the PerIsolateSimulatorData. Original change's description: > [fastcall] Enable float support on arm64 simulator > > This CL adds support for handling calls to C functions with arbitrary > signatures on the arm64 simulator. It adds infrastructure for > encoding the signature data from CallDescriptor and FunctionInfo > classes into a compact representation, stored in the simulator and > called EncodedCSignature. > > Design doc: > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit > > This CL is a follow up on the native support added in > https://chromium-review.googlesource.com/c/v8/v8/+/3182232 > and is partially based on the previous attempt: > https://chromium-review.googlesource.com/c/v8/v8/+/2343072 > > Bug: chromium:1052746 > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77744} Bug: chromium:1052746, chromium:1267854 Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#78018}
-
- 11 Nov, 2021 1 commit
-
-
Liu Yu authored
The second parameter of Int64Mul may be a 64-bit immediate value, treating it as a 32-bit value will lose the upper 32 bits. Besides, add a test for this error. Bug: v8:12373 Change-Id: I92e95f7906051c91f9076730e5490b0956416d68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272195 Auto-Submit: Liu yu <liuyu@loongson.cn> Commit-Queue: Liu yu <liuyu@loongson.cn> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#77833}
-
- 09 Nov, 2021 1 commit
-
-
Maya Lekova authored
This reverts commit b9ddcbc8. Reason for revert: Hits unreachable on MSAN, see https://bugs.chromium.org/p/chromium/issues/detail?id=1267854 Original change's description: > [fastcall] Enable float support on arm64 simulator > > This CL adds support for handling calls to C functions with arbitrary > signatures on the arm64 simulator. It adds infrastructure for > encoding the signature data from CallDescriptor and FunctionInfo > classes into a compact representation, stored in the simulator and > called EncodedCSignature. > > Design doc: > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit > > This CL is a follow up on the native support added in > https://chromium-review.googlesource.com/c/v8/v8/+/3182232 > and is partially based on the previous attempt: > https://chromium-review.googlesource.com/c/v8/v8/+/2343072 > > Bug: chromium:1052746 > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486 > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77744} Bug: chromium:1052746, chromium:1267854, chromium:1267841 Change-Id: If3d5aaab6b5f4309ce90add614d674aaa86b43c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268910 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77788}
-
- 08 Nov, 2021 2 commits
-
-
Igor Sheludko authored
This CL * adds forwarding accessors to CodeDataContainer for certain widely used Code object's fields and predicates, * adds JSFunction::set_code() overloads accepting CodeT values, * migrates SharedFunctionInfo getters to CodeT, * migrates InterpreterData::interpreter_trampoline to CodeT. Drive-by-fix: replace #if V8_EXTERNAL_CODE_SPACE with #ifdef to be consistent. Bug: v8:11880 Change-Id: I1e114076a0568068038ca6f70a86431a3a9cfb9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3262716 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#77762}
-
Maya Lekova authored
This CL fixes a null dereference when an attempt is made to access the current arm64 simulator from a background thread. Bug: chromium:1267491 Change-Id: I9232fe134fccbff162eb5076aff20884872e4cc7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264219 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77757}
-
- 05 Nov, 2021 1 commit
-
-
Maya Lekova authored
This CL adds support for handling calls to C functions with arbitrary signatures on the arm64 simulator. It adds infrastructure for encoding the signature data from CallDescriptor and FunctionInfo classes into a compact representation, stored in the simulator and called EncodedCSignature. Design doc: https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit This CL is a follow up on the native support added in https://chromium-review.googlesource.com/c/v8/v8/+/3182232 and is partially based on the previous attempt: https://chromium-review.googlesource.com/c/v8/v8/+/2343072 Bug: chromium:1052746 Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77744}
-
- 02 Nov, 2021 1 commit
-
-
Maya Lekova authored
This CL adds a minor change to the arm/arm64 simulators to support up to 20 arguments in a C function call. This change is necessary for an upcoming CL which adds float support to the simulator and tests with more than 20 arguments, see https://chromium-review.googlesource.com/c/v8/v8/+/3060486 Bug: chromium:1052746 Change-Id: I60ae603c96554525d28f1cd248d7766f86c9cc3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256785 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77651}
-
- 28 Oct, 2021 1 commit
-
-
Ng Zhi An authored
4 instructions, int32x4.trunc_f32x4_{s,u}, int32x4.trunc_f64x2_{s,u}_zero. Drive-by cleanup to wasm-interpreter to use saturated_cast. The machine ops are named <int>Trunc<float>, dropping the "sat" since these don't do any saturation anymore. Bug: v8:12284 Change-Id: I2d4d6a61b819b287fee69e3eea03dd3151cfa10d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3223166Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77598}
-
- 26 Oct, 2021 1 commit
-
-
Clemens Backes authored
The dominator tree is usually computed as part of scheduling (in {Scheduler::ComputeSchedule}). For tests it was missing, leading to DCHECK errors in the mid-tier register allocator, which uses the dominator tree. R=mslekova@chromium.org Bug: v8:12330 Change-Id: I02bc8dee3aecb6a1613fa1d07d3aae85cd28de17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245114Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#77543}
-
- 12 Oct, 2021 1 commit
-
-
Camillo Bruni authored
Bug: v8:12298, chromium:1244145 Change-Id: Ic97fea06cd3ede330ad7c67c00bfb567006c3ac4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211891 Auto-Submit: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#77336}
-
- 27 Sep, 2021 1 commit
-
-
Andreas Haas authored
Bug: v8:12244 Change-Id: Ia99fac6e7001bb6bce12256d3fcce28e45222f7d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3182229Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#77094}
-
- 09 Sep, 2021 1 commit
-
-
Ilja Iskovs authored
Use an immediate zero operand for floating point comparison nodes when possible. This results in up to 20-25% runtime improvement in some microbenchmarks, as well as 1-1.5% runtime improvement in some real-use benchmarks on Cortex-A55 and Neoverse N1. Change-Id: I39d10871a08a037dbe8c0877d789d110476e1a58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3133143Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Cr-Commit-Position: refs/heads/main@{#76749}
-
- 06 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Remove the BaselineData intermediate structure for baseline code, and write the baseline Code object into the SharedFunctionInfo directly. We still need a pointer to the BytecodeArray/InterpreterData, so re-use the Code object's deoptimization data slot for this (baseline code doesn't have deoptimization data). A consequence of this is that the BytecodeArray pointer becomes immutable when there is baseline code. This means that we cannot install a debug BytecodeArray while baseline code is active (we have to flush it first), and we can't tier-up code with debug BytecodeArray to baseline. Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76675}
-
- 24 Aug, 2021 1 commit
-
-
Dan Elphick authored
This is a reland of d1b27019 Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
-
- 23 Aug, 2021 2 commits
-
-
Dan Elphick authored
This reverts commit d1b27019. Reason for revert: Broke vtune build, tsan build and possibly others Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Bug: v8:11965 Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76428}
-
Dan Elphick authored
This moves every single class/function out of include/v8.h into a separate header in include/, which v8.h then includes so that externally nothing appears to have changed. Every include of v8.h from inside v8 has been changed to a more fine-grained include. Previously inline functions defined at the bottom of v8.h would call private non-inline functions in the V8 class. Since that class is now in v8-initialization.h and is rarely included (as that would create dependency cycles), this is not possible and so those methods have been moved out of the V8 class into the namespace v8::api_internal. None of the previous files in include/ now #include v8.h, which means if embedders were relying on this transitive dependency then it will give compile failures. v8-inspector.h does depend on v8-scripts.h for the time being to ensure that Chrome continue to compile but that change will be reverted once those transitive #includes in chrome are changed to include it directly. Full design: https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing Bug: v8:11965 Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76424}
-
- 19 Aug, 2021 3 commits
-
-
Shu-yu Guo authored
This is a reland of faf2208a Changes since revert: - Fix arm64 codegen for full pointer mode Original change's description: > [compiler] Support acq/rel accesses and atomic accesses on tagged > > This CL adds an AtomicMemoryOrder parameter to the various atomic load > and store operators. Currently only acquire release (kAcqRel) and > sequentially consistent (kSeqCst) orders are supported. > > Additionally, atomic loads and stores are extended to work with tagged > values. > > This CL is a pre-requisite for supporting atomic accesses in Torque, > which is in turn a pre-requisite for prototyping shared strings. > > Bug: v8:11995 > Change-Id: Ic77d2640e2dc7e5581b1211a054c93210c219355 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101765 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Zhi An Ng <zhin@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76393} Bug: v8:11995 Change-Id: I23577486334fec6b08fb3a2f5be1f6e5e16db11b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3107220Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#76399}
-
Nico Hartmann authored
This reverts commit faf2208a. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression/10870/overview Original change's description: > [compiler] Support acq/rel accesses and atomic accesses on tagged > > This CL adds an AtomicMemoryOrder parameter to the various atomic load > and store operators. Currently only acquire release (kAcqRel) and > sequentially consistent (kSeqCst) orders are supported. > > Additionally, atomic loads and stores are extended to work with tagged > values. > > This CL is a pre-requisite for supporting atomic accesses in Torque, > which is in turn a pre-requisite for prototyping shared strings. > > Bug: v8:11995 > Change-Id: Ic77d2640e2dc7e5581b1211a054c93210c219355 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101765 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Zhi An Ng <zhin@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76393} Bug: v8:11995 Change-Id: Id9936672f9e96c509b1cdf866de1ac5303996945 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3107229Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#76394}
-
Shu-yu Guo authored
This CL adds an AtomicMemoryOrder parameter to the various atomic load and store operators. Currently only acquire release (kAcqRel) and sequentially consistent (kSeqCst) orders are supported. Additionally, atomic loads and stores are extended to work with tagged values. This CL is a pre-requisite for supporting atomic accesses in Torque, which is in turn a pre-requisite for prototyping shared strings. Bug: v8:11995 Change-Id: Ic77d2640e2dc7e5581b1211a054c93210c219355 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101765Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#76393}
-
- 17 Aug, 2021 1 commit
-
-
Leszek Swirski authored
Make off-thread deserialization play well with the Isolate compilation cache, by moving the Finish call into GetSharedFunctionInfoForScript. This means that a) The isolate cache is checked before the Finish, allowing it to be hit, and b) Results of off-thread deserializations are written into the Isolate cache. Bug: chromium:1075999 Change-Id: I535935180bbe77f3e718253830e649bd62857634 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094006 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#76341}
-
- 16 Aug, 2021 2 commits
-
-
Georg Neis authored
Also remove remnants of x87 port. Change-Id: I3376539504d2a04c9f918ab39d0976eaca31782f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097866 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76313}
-
Yu Yin authored
Bug: v8:12008 Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76308}
-
- 12 Aug, 2021 1 commit
-
-
Ross McIlroy authored
These are no longer enabled, so remove the code mitigation logic from the codebase. BUG=chromium:1003890 Change-Id: I536bb1732e8463281c21da446bbba8f47ede8ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045704 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76256}
-
- 11 Aug, 2021 1 commit
-
-
Nico Hartmann authored
When running d8 with --trace-deopt, any deopt will contain the id of the node that caused this deopt. These ids also show up in the deoptimization data table of when using --print-opt-code. Change-Id: I412ca7a4ff20427100fa63101d78ee3846569a8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024144Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#76220}
-
- 05 Aug, 2021 1 commit
-
-
Jakob Gruber authored
Bug: v8:7790 Change-Id: Ia5903364a774bd49db1a646b3066b9972deac725 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074465 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76119}
-
- 04 Aug, 2021 2 commits
-
-
Camillo Bruni authored
- Add separate script-details.h file - Follow-up CL will add support for precise caching with custom host options Bug: v8:10284 Change-Id: I37be2079434ba7029c160ca811c7ce00a147f539 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069151 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76077}
-
Camillo Bruni authored
Follow-up CLs will use the ScriptDetails object for code cache lookups instead of only the ScriptOriginOptions. Bug: v8:10284 Change-Id: Idc83e6e79cfca283369a9b5ceab8bc53dae5f2dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069149 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76073}
-
- 03 Aug, 2021 2 commits
-
-
Seth Brenith authored
While reading through the jump threading implementation, I noticed something strange: ApplyForwarding iterates through the block list in reverse post-order, not in assembly order. Thus, the value prev_fallthru might not refer to the previous block in assembly order. Obviously it works fine this way or we would have noticed by now, but I think that this step would be a little easier to read and reason about if the iteration used assembly order instead. I've added a test case to demonstrate the difference when using assembly order: in a diamond where the right side starts with an empty deferred block, the current implementation would fail to replace that block with a nop. I doubt this case would have any real-world impact. Change-Id: I28abe2043434debb54896871d15c540ad52c6368 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3039261 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76067}
-
Jakob Gruber authored
Based on a CL by mvstanton@. Bug: v8:7790,v8:12030,v8:12031,v8:12041 Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76055}
-
- 23 Jul, 2021 1 commit
-
-
Paolo Severini authored
Enabling --turbo-optimize-apply breaks tests because we are passing the wrong receiver; in JSCallReducer::ReduceCallOrConstructWithArrayLikeOrSpread we create a Call node with the wrong ConvertReceiverMode, we pass kNullOrUndefined while it should be kAny. This may break calls to API or in general calls to functions that use the receiver. Bug: chromium:1231108, v8:9974 Change-Id: Ib35a1bf8746ad254b6d63274f3ae11b12aa83de8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043690 Commit-Queue: Paolo Severini <paolosev@microsoft.com> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#75886}
-
- 19 Jul, 2021 1 commit
-
-
Jakob Gruber authored
This wraps up the transition away from kSerialized ref kinds. Since JSFunctionRef is a complex type, we don't attempt full consistency on the background thread. Instead, we serialize functions on the background in a partially-racy manner, in which consistency between different JSFunction fields is *not* guaranteed. Consistency is later verified through a new compilation dependency kind during finalization. Bug: v8:7790, v8:12004 Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75789}
-
- 07 Jul, 2021 1 commit
-
-
Peter Kasting authored
Bug: chromium:989932 Change-Id: I357a19a9da934f07181122bbf50614ccddce3a4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009926 Auto-Submit: Peter Kasting <pkasting@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#75612}
-
- 01 Jul, 2021 2 commits
-
-
Peter Kasting authored
There are still a few cases remaining that seem more controversial; I'll upload those separately. Bug: chromium:1066980 Change-Id: Iabbaf23f9bbe97781857c0c589f2b3db685dfdc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994804 Commit-Queue: Peter Kasting <pkasting@chromium.org> Auto-Submit: Peter Kasting <pkasting@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75494}
-
Liu Yu authored
Fix a offset error, this is related to commit 38fb1487 Delete cctest/test-run-machops/StackSlotAlignment, this is related to commit a58f812c Change-Id: I3ef1b96d8a3bdba530200cbac4f7a062496ace59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994813Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Auto-Submit: Liu yu <liuyu@loongson.cn> Cr-Commit-Position: refs/heads/master@{#75493}
-
- 22 Jun, 2021 1 commit
-
-
Georg Neis authored
It was not in sync with the optimization, which relies on inspecting up the length and name fields even for bound functions. To make a now meaningful serializer test actually pass, I have to to make some changes to the test setup. I'm also moving the function name and length index constants from JSFunction to JSFunctionOrBoundFunction for clarity. TBR=marja@chromium.org Bug: v8:7790 Change-Id: I36dd3c80996ccb53810c7ea9bfceb5c84ffd60ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972919 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#75299}
-
- 21 Jun, 2021 1 commit
-
-
Clemens Backes authored
The WasmEngine is shared across the whole process, so there is no need to store it in every Isolate. Instead, we can just get it from everywhere on any thread using {wasm::GetWasmEngine()}, which is a simple read of a global. R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I13afb8ca3d116aa14bfaec5a4bbd6d71faa9aa17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969825Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75265}
-
- 18 Jun, 2021 2 commits
-
-
Vasili Skurydzin authored
When result is returned in a register to the calling code, some GCC versions use 32 bit compare, and some use 64 bit compare. In the case comparison is 64 bit, GCC on PPC64 arch is expecting the return value to be sign-extended, leading to an error in comparison. Change-Id: I05b7e1566bc9bb931ce9998bb310eb29c50e90e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968449Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Vasili Skurydzin <vasili.skurydzin@ibm.com> Cr-Commit-Position: refs/heads/master@{#75245}
-
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
- 17 Jun, 2021 2 commits
-
-
Toon Verwaest authored
This isn't used outside of tests, so let's just remove it. Change-Id: I06b7ec11911fd8ebc3bbabcba16d0c2a3fafddab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968413Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75220}
-
Toon Verwaest authored
This also removes intrinsics that were just used in tests. It keeps InlineIncBlockCounter for now because it's a less straightforward. Change-Id: I77e55d7a746294892d0fd7ab577ebf8eb42f1f08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953195 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75217}
-