| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[heap] Split off trusted methods into TrustedHeapLayout This should make it easier for callers to see which calls can be trusted wrt to the V8 sandbox and which calls yield in untrusted data. Bug: 429538831 Change-Id: I4939d69665197e5de75ab5757edacc7f73c76745 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6889553 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#102070} | 10 个月前 | |
[x64] Use the flags set by -march for snapshot. When generating the builtins for the snapshot we might as well make use of any CPU features implied by the -march flag of the C++ compiler. The resulting binary will only work on CPUs that support these flags, so there's no harm in using them in the builtins. Change-Id: I23f816e6584c58102633c8c9fbdc7a62905a7f5a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7151303 Reviewed-by: Erik Corry <erikcorry@chromium.org> Commit-Queue: Erik Corry <erikcorry@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#103716} | 7 个月前 | |
Sparkplug+: support patchable baseline code A bytecode handler for an operation is often a generic handler that deal with different types of inputs. This make the baseline compiler to generate a call to a generic builtin for that operation. The generic builtin can deal with all types of inputs, but this makes the builtin very large and introduces a lot of branches to distinguish inputs' types, which hurts the performance. Sparkplug+ introduces some small and specific handlers to deal with one single type of input. For example, this CL introduces some small monomorphic handlers for builtin LoadIC to deal with one specific kind of IC. We will patch the baseline code to use these specific handlers on IC misses dynamically. Bug: chromium:429351411 Change-Id: I85f842ae4050eebbdd8d25d5e113deae743c95d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6627216 Commit-Queue: Xu, Hao A <hao.a.xu@intel.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#103495} | 8 个月前 | |
[x64][deopt] Zap code objects marked for lazy deopt The identification of code objects that should be deoptimized and the actual deoptimization happen at different points in time. It can therefore happen that deoptimization does not happen even though a code object is marked for deoptimization. With this CL, code objects on x64 get zapped with int3 the moment they are marked for deoptimization. Therefore, if for whatever reason deoptimization fails later, execution of that code object cannot continue, as it will cause a crash immediately. Bug: 422364570, 422951610 Change-Id: I93c31cafd24014f8a53b961ee7b78d3da7ef2af7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6624355 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#100968} | 1 年前 | |
third_party: Move valgrind - Move src/third_party_valgrind/ to third_party/valgrind - Add README.v8 Bug: 383356859 Change-Id: I7f6b3471648707c0f40c72d687f4261711056454 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6088199 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#97756} | 1 年前 | |
[x64] Implement 256-bit assembly for some FMA instructions Bug: v8:12228 Change-Id: Ia99469472f9d69aed5fb6ea1a3689dc8ddf304da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4548680 Reviewed-by: Darius Mercadier <dmercadier@chromium.org> Commit-Queue: Yuheng Wei <yuheng.wei@intel.com> Cr-Commit-Position: refs/heads/main@{#92912} | 2 年前 | |
Reland^2 "Embedding feedback in BytecodeArray for StrictEqual" This is a reland of commit e295f1f18da01c386eda73f535fb67a56c004d88 Original change's description: > Reland "Embedding feedback in BytecodeArray for StrictEqual" > > This is a reland of commit f0fed41e48b1966e3e565ae278d018da538ef123 > > Original change's description: > > Embedding feedback in BytecodeArray for StrictEqual > > > > This CL removes the feedback vector slot for StrictEqual and stores its feedback values directly in the BytecodeArray. Optimized compilers will now access the type feedback from the BytecodeArray. > > > > Before: > > 75 04 00 TestEqualStrict a1, [0] > > > > After: > > 75 04 00 00 TestEqualStrict a1, #0 > > > > This change saves moemory by reducing FeedbackVector size, and is part of the Sparkplug+ optimization effort. > > > > Bug: chromium:429351411 > > Change-Id: I24390811c12755b0a19beaefe2b0319d75ceaf6c > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6986847 > > Reviewed-by: Xu, Hao A <hao.a.xu@intel.com> > > Commit-Queue: Wei, Yuheng <yuheng.wei@intel.com> > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#103656} > > Bug: chromium:429351411 > Change-Id: I77286b0e9c65f8a9e257a2125adab7f68fe09aec > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7148333 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Wei, Yuheng <yuheng.wei@intel.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#103800} Bug: chromium:429351411 Change-Id: I5020c9dffbed90ff207520728b13cf0dbcfb5903 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7197099 Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Wei, Yuheng <yuheng.wei@intel.com> Cr-Commit-Position: refs/heads/main@{#103962} | 7 个月前 | |
【CVE-2026-4450】【487746373】【490642836】【CVE-2026-4457】【488803413】[CVE-2026-4461][490558172][489159859][481749436][491191100][492077213][496629079][472181383][480442279][481295170][485784597][474402856][483220222] Signed-off-by: Marja Hölttä <marja@chromium.org> | 28 天前 | |
【CVE-2026-4450】【487746373】【490642836】【CVE-2026-4457】【488803413】[CVE-2026-4461][490558172][489159859][481749436][491191100][492077213][496629079][472181383][480442279][481295170][485784597][474402856][483220222] Signed-off-by: Marja Hölttä <marja@chromium.org> | 28 天前 | |
Reland "[compiler] Handle deopt in the fast API" This is a reland of commit 3da1691dd7f64aa5514b1765f12f3900d030fa0c The original CL opened a WritableJitAllocation scope in the deoptimizer before calling PatchToJump to allow modifying generated code on M1. However, this scope caused problems with pkeys on x64. This CL now opens an RwxMemoryWriteScope inside the arm64 implementation of PatchToJump to avoid the problem. The original CL opened a WritableJitAllocation scope in the deoptimizer before calling PatchToJump to allow modifying generated code on M1. However, this scope caused problems with pkeys on x64. This CL now opens an RwxMemoryWriteScope inside the arm64 implementation of PatchToJump to avoid the problem. Original change's description: > [compiler] Handle deopt in the fast API > > Deopt with fast API is different than normal deopts in the following ways: > 1) Normal deopts (without CFI) patch the return address on the stack to return to the deopt trampoline; with fast API calls, the generated code is patched to jump to the deopt trampoline after returning from the fast call; > > 2) With CFI, the generated code also gets patched, but for fast calls the jump is not patched right after the return address, but after the code that restores the stack pointer. > > 3) The DeoptimizationEntry_LazyAfterFastCall builtin has to check and handle pending exceptions before tail-calling to DeoptimizationEntry_Lazy. > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6532354 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/main@{#100421} BYPASS_LARGE_CHANGE_WARNING Change-Id: I8fd8fe49db98c48e325c1084d2b08fc093f8f88d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6578320 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#100439} | 1 年前 | |
[codegen] Change RegList into a class Modernise the RegList interface to be a proper class, rather than a typedef to an integer, and add proper methods onto it rather than ad-hoc bit manipulation. In particular, this makes RegList typesafe, adding a DoubleRegList for DoubleRegisters. The Arm64 CPURegList isn't updated to use (or extend) the new RegList interface, because of its weird type-erasing semantics (it can store Registers and VRegisters). Maybe in the future we'll want to get rid of CPURegList entirely and use RegList/DoubleRegList directly. Change-Id: I3cb2a4d386cb92a4dcd2edbdd3fba9ef71f354d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516747 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79460} | 4 年前 | |
[x64] Implement 256-bit assembly for SSE4_UNOP instructions Bug: v8:12228 Change-Id: Icd61de973b4d80bd81a2bbbf9db621315fb21a3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4535539 Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Yolanda Chen <yolanda.chen@intel.com> Cr-Commit-Position: refs/heads/main@{#87781} | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 10 个月前 | ||
| 7 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 7 个月前 | ||
| 28 天前 | ||
| 28 天前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 3 年前 |