- 27 Mar, 2018 1 commit
-
-
Tobias Tebbi authored
This CL changes the poisoning in the interpreter to use the infrastructure used in the JIT. This does not change the original flag semantics: --branch-load-poisoning enables JIT mitigations as before. --untrusted-code-mitigation enables the interpreter mitigations (now realized using the compiler back-end), but does not enable the back-end based mitigations for the Javascript JIT. So in effect --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers use the same mechanics (including changed register allocation) that --branch-load-poisoning enables for the JIT. Bug: chromium:798964 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27 Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#52243}
-
- 12 Feb, 2018 1 commit
-
-
Ross McIlroy authored
Moves generation of speculation poison to be based on the PC target vs the actual PC being executed. The speculation poison is generated in the prologue of the generated code if CompilationInfo::kGenerateSpeculationPoison is set. The result is stored in a known register, which can then be read using the SpeculationPoison machine node. Currently we need to ensure the SpeculationPoison node is scheduled right after the code prologue so that the poison register doesn't get clobbered. This is currently not verified, however it's only use is in RawMachineAssembler where it is manually scheduled early. The Ignition bytecode handlers are updated to use this speculation poison rather than one generated by comparing the target bytecode. BUG=chromium:798964 Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2 Reviewed-on: https://chromium-review.googlesource.com/893160 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51229}
-
- 29 Jan, 2018 1 commit
-
-
Ross McIlroy authored
BUG=chromium:798964 Change-Id: I63c373ef3f27a3295fc79f5c82d78b5fd89a83da Reviewed-on: https://chromium-review.googlesource.com/888752 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#50925}
-
- 19 Oct, 2017 1 commit
-
-
Mostyn Bramley-Moore authored
This makes jumbo_file_merge_limit=50 work again. Bug: chromium:770684 Change-Id: I5db6566da876d71ea6ba50ff03b7652074b0a35f Reviewed-on: https://chromium-review.googlesource.com/725818Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com> Cr-Commit-Position: refs/heads/master@{#48728}
-
- 28 Dec, 2016 1 commit
-
-
ishell authored
... and add explicit CallPrologue/CallEpilogue callbacks to CodeAssemblerState instead. This will allow IntepreterAssembler to use any other helper assembler. TBR=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2600183004 Cr-Commit-Position: refs/heads/master@{#41973}
-
- 16 Nov, 2016 2 commits
-
-
jkummerow authored
This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Original review: https://codereview.chromium.org/2498073002/ Review-Url: https://codereview.chromium.org/2502293002 Cr-Commit-Position: refs/heads/master@{#41028}
-
machenbach authored
Revert of [refactoring] Split CodeAssemblerState out of CodeAssembler (patchset #8 id:140001 of https://codereview.chromium.org/2498073002/ ) Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared doesn't want to compile. Missing export annotation? Original issue's description: > [refactoring] Split CodeAssemblerState out of CodeAssembler > > This is in preparation for introducing more specialized > CodeStubAssembler subclasses. The state object can be handed > around, while the Assembler instances are temporary-scoped. > > BUG=v8:5628 TBR=ishell@chromium.org,mstarzinger@chromium.org,jkummerow@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5628 Review-Url: https://codereview.chromium.org/2504913002 Cr-Commit-Position: refs/heads/master@{#41018}
-
- 15 Nov, 2016 1 commit
-
-
jkummerow authored
This is in preparation for introducing more specialized CodeStubAssembler subclasses. The state object can be handed around, while the Assembler instances are temporary-scoped. BUG=v8:5628 Review-Url: https://codereview.chromium.org/2498073002 Cr-Commit-Position: refs/heads/master@{#41015}
-
- 12 Aug, 2016 1 commit
-
-
mstarzinger authored
This removes some compiler internals as well as some JavaScript specific helper from the CodeAssembler, by either hiding or moving the support into the CodeStubAssembler. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2246463002 Cr-Commit-Position: refs/heads/master@{#38617}
-
- 06 Apr, 2016 1 commit
-
-
oth authored
Anotates bytecodes with a description of how each uses the accumulator. Validates annotations and uses of accumulator when generating bytecode handlers. Only prints the accumulator during tracing where used. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1852213002 Cr-Commit-Position: refs/heads/master@{#35281}
-
- 21 Mar, 2016 1 commit
-
-
oth authored
This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
-
- 10 Feb, 2016 1 commit
-
-
rmcilroy authored
Moves InterpreterAssembler out of the compiler directory and into the interpreter directory. Makes InterpreterAssembler as subclass of CodeStubAssembler. As part of this change, the special bytecode dispatch linkage type is removed and instead we use a InterfaceDispatchDescriptor and a normal CodeStub linkage type. Removes a bunch of duplicated logic in InterpreterAssembler and instead uses the CodeStubAssembler logic. Refactors Interpreter with these changes. Modifies CodeStubAssembler to add the extra operations required by the Interpreter (extra call types, raw memory access and some extra binary ops). Also adds the ability for subclasses to add extra prologue and epilogue operations around calls, which is required for the Interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1673333004 Cr-Commit-Position: refs/heads/master@{#33873}
-