- 20 Apr, 2020 30 commits
-
-
Francis McCabe authored
This reverts commit 0a59e0cb. Reason for revert: Still causing UBSAN issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729 Original change's description: > Reland^2 "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of d91679bf > which was a reland of d91679bf > > Fixes missing initialization of ParserBase::allow_eval_cache_ > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org > > Bug: v8:10314 > Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67245} TBR=rmcilroy@chromium.org,leszeks@chromium.org Change-Id: I1c5f58cc5608217a149b04aa6f50bb3d7606c26d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157657Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67250}
-
Francis McCabe authored
This reverts commit 4158af83. Reason for revert: causing UBSAN failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729? Original change's description: > [turbofan] Fix bug in Number.Min/Max typings > > They try to be very precise about when the result can be -0, > but do so incorrectly. I'm changing the code to just do the > simple thing instead. Let's see how that affects performance. > > Bug: chromium:1072171 > Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67246} TBR=neis@chromium.org,tebbi@chromium.org Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1072171 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67249}
-
Tobias Tebbi authored
Change-Id: Ic372c7b7b308650518d0ddf938c389cfb7c2ea07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137407 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67248}
-
Tobias Tebbi authored
To enable this, the following changes were necessary: - Fix generation of accessors with MaybeObject type and a bunch of include problems. - Torque-generated C++ classes now have a constructor that can allow Smi values to enable a hack currently used for the DescriptorArray. Bug: v8:7793 v8:8983 Change-Id: If6e35db99199a0e2afd2698af3d84777d6d0b18f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108036 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#67247}
-
Georg Neis authored
They try to be very precise about when the result can be -0, but do so incorrectly. I'm changing the code to just do the simple thing instead. Let's see how that affects performance. Bug: chromium:1072171 Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67246}
-
Leszek Swirski authored
This is a reland of d91679bf which was a reland of d91679bf Fixes missing initialization of ParserBase::allow_eval_cache_ Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org Bug: v8:10314 Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67245}
-
Clemens Backes authored
The flag is on by default, and tests already rely on the new behaviour. This CL removes the flag and immediately affected code. More code will be removed component by component in follow-up CLs. Drive-by: Inline {RemoveBreakpointFromInfo} into {ClearBreakPoint}, which only redirected to that method after this CL. R=thibaudm@chromium.org,bmeurer@chromium.org Bug: v8:10389, v8:10351 Change-Id: I3b18e228dd633cfb25541ddd0f31699b1ceb1db0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154804 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67244}
-
Jakob Kummerow authored
Random-generated modules can take surprising code paths. Bug: chromium:1072127, chromium:1072115 Change-Id: Id9973ebe5942e95e6006026c8cbf875d826d355a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2156765Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67243}
-
Leszek Swirski authored
This reverts commit 146f5375. Reason for revert: UBSan (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10726?) Original change's description: > Reland "[parser] Introduce UnoptimizedCompileFlags" > > This is a reland of d91679bf > > This reland adds initializers for the output flags. > > Original change's description: > > [parser] Introduce UnoptimizedCompileFlags > > > > UnoptimizedCompileFlags defines the input flags shared between parse and > > compile (currently parse-only). It is set initially with some values, and > > is immutable after being passed to ParseInfo (ParseInfo still has getters > > for the fields, but no setters). > > > > Since a few of the existing flags were output flags, ParseInfo now has a > > new output_flags field, which will eventually migrate to a ParseOutputs > > structure. > > > > Bug: v8:10314 > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Simon Zünd <szuend@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#66782} > > Bug: v8:10314 > Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67241} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: I204eb9e4d0a5bfaeeefeb6b0f1c82856b57cb175 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157029Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67242}
-
Leszek Swirski authored
This is a reland of d91679bf This reland adds initializers for the output flags. Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} Bug: v8:10314 Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67241}
-
Milad Farazmand authored
Port 1d8f1376 R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I1fed871f0722084859f527e0745011b7e01e9631 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2155415Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67240}
-
Sami Kyostila authored
This patch adds a new category group for v8.gc + devtools and adds a missing dependency on Perfetto's generated headers. Bug: chromium:1006766 Change-Id: Id92fdc0b938d25ab0df5ada936d3f987cc6ec5f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2156767 Commit-Queue: Sami Kyöstilä <skyostil@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Auto-Submit: Sami Kyöstilä <skyostil@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#67239}
-
Michael Achenbach authored
This keeps it whitelisted for normal fuzzing. TBR=neis@chromium.org Bug: chromium:1070890, v8:10249 Change-Id: I9011db08741e1eef98672847809e7beb2abfe93b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154789Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#67238}
-
Georg Neis authored
is not enough This CL records the inlined bytecode size in code objects and take it into consideration when calculating inline candidate's size. It can improve Speedometer2 by ~1% and JetStream2 by ~3% on 9900K platform. Contributted by tao.pan@intel.com Change-Id: Icf31ca52ed5013d62a9c8d5dd550944ef3a4fbda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089021Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67237}
-
Michael Achenbach authored
Bug: chromium:1044942, v8:10249 Change-Id: I7e6b7cb669697b89dd493db35c04f76106b710aa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154787Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#67236}
-
Omer Katz authored
Bug: chromium:1056170 Change-Id: Ifc519559868d9c3099d309f75ba8faf2018a1578 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154951 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#67235}
-
Clemens Backes authored
This reverts commit f5bee002. Reason for revert: Crashes android webview, see https://crbug.com/1071708. Original change's description: > Revisiting auxvec data gathering for PPC/ARM. > > /proc/sys/auxv might not be accessible, instead > getting these from the user's stack. > > Change-Id: I2dcf696734e2b4dc1da27a991930b9e0d4228d51 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730990 > Commit-Queue: Clemens Backes [né Hammacher] <clemensb@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Clemens Backes [né Hammacher] <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64037} TBR=clemensb@chromium.org,bmeurer@chromium.org,devnexen@gmail.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1071708 Change-Id: I05659f245c1020e98b7225a25e82987d9955d595 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154800Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67234}
-
Leszek Swirski authored
Bug: chromium:1011762 Change-Id: I99d7d48543972c2de8c1728a75a81b6e83f0064f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122030 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67233}
-
Marja Hölttä authored
It doesn't need to implement its own iteration logic, if we refactor a bit. BUG=v8:10425 Change-Id: I9b33911c2fab9ac85cae847473dbef0c2e88ea96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153224Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67232}
-
Ulan Degenbaev authored
This reverts commit ecc61b30. Reason for revert: I will reland with the flag disabled. Original change's description: > [heap] Add a flag for performing incremental marking on allocation > > The flag is true by default and passing > --noincremental-marking-on-allocation disables starting of incremental > marking on allocation and incremental marking steps on allocation. > > Change-Id: I4537e0eeaaf93fb713fcacd3860e29b98df441fc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154194 > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67228} TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org Change-Id: I7dd847513d1628e7137d9e10cb5e9058781a9634 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154803Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67231}
-
Leszek Swirski authored
Space::AllocationStep already allocates a filler object at the given address, so there's no need to do another filler object allocation in the sampling profiler. In addition, this breaks allocation stepping over areas that have already been initialized, such as off-thread pages being merged. Instead, we replace it with a DCHECK that there is a map at the start of the allocated chunk, which serves as a proxy for "this area is iteratable" Change-Id: Ia0a1375ac83b944cf5631e6bef341805d27b6e96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122029 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67230}
-
Michael Achenbach authored
NOTRY=true Bug: v8:10249 Change-Id: I349d877688c6ea86db9974f28c32b02014b58ba2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154791Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#67229}
-
Ulan Degenbaev authored
The flag is true by default and passing --noincremental-marking-on-allocation disables starting of incremental marking on allocation and incremental marking steps on allocation. Change-Id: I4537e0eeaaf93fb713fcacd3860e29b98df441fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154194Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67228}
-
Ulan Degenbaev authored
These GC events will not be visualized in DevTools UI. The intention is to have these events in JSON trace file for manual inspection during offline/postmortem investigation of GC performance issues. Bug: chromium:1072352 Change-Id: I3b05a0b2e5299f9d00d4c940eaf598a48f746aa2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154796Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67227}
-
Mythri A authored
The fast store handlers create elements and if we have a typed array on the prototype chain it is not easy to check when it is OK to create new elements. The TypedArrays swallow all OOB stores, and there is no easy way to check if the current store is OOB for JSObjects. So use slow stub when there are typed arrays on the prorotype chain of JSObjects. Bug: chromium:1068492 Change-Id: I9eea9cf00e3eb84931c5545d18ba53c4ec39f353 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134138 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#67226}
-
Sathya Gunasekaran authored
Previously, one single retained maps list was used across all contexts. When one context was disposed, this entire list of retained maps was disposed as well. This caused maps that were still alive to be disposed leading to deopts when such maps were embedded in code objects. This patch makes the list of retained maps be per context so we can dispose only the dead maps. Bug: v8:9684, v8:10431 Change-Id: I0a50f4f49c9f6d72367c62e950828a039220fdfc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122016Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#67225}
-
Marja Hölttä authored
Spec: https://github.com/tc39/proposal-promise-any Bug: v8:9808 Change-Id: I568b2444df9f00f615f2cda1268e4ecc5b36667e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139571 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#67224}
-
Ulan Degenbaev authored
Deserializer can trigger OOB read in the marking bitmap inside the RegisterDeserializedObjectsForBlackAllocation function. This happens for example if an internalized string is deserialized as the last object on a page and is the turned into a thin-string leaving a one-word filler at the end of the page. In such a case IsBlack(filler) will try to fetch a cell outside the marking bitmap. The fix is to increase the size of the marking bitmap by one cell, so that it is always safe to query markbits of any object on a page. Bug: chromium:978156 Change-Id: If3c74e4f97d2caeb3c3f37a4147f38dea5f0e5a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2152838 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#67223}
-
Georg Neis authored
... against potential typer bugs. Instead of simply eliminating the operation, insert an aborting bounds check instead. Also move this transformation out of SimplifiedLowering, which is already complex enough without doing these kinds of optimizations. Unfortunately this will result in some missed optimization opportunities because we may have more precise types during SimplifiedLowering. Let's see if this makes a visible performance difference. Change-Id: I9c16ad33104c29fdba39bf729d69ee03fc9797d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129633 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67222}
-
Zhao Jiazhong authored
Port 1d8f1376 https://crrev.com/c/2154048 Change-Id: I7237e784d86cd78e936741a47887c2efe731cbbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2156165Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#67221}
-
- 19 Apr, 2020 1 commit
-
-
Michael Achenbach authored
Bug: chromium:1063568 Change-Id: I69ae644cc02549eb6c8c3b6169e9b1db2ee4e27e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144067 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67220}
-
- 18 Apr, 2020 2 commits
-
-
Shu-yu Guo authored
Both features shipped in M80. Bug: v8:9547, v8:9553 Change-Id: I7a34db05796f22bcc112c36a42826e7c926a7364 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154768 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67219}
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I95262d0ab550d41b7c5e2ce4eb9ec8164c53e892 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154048Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/master@{#67218}
-
- 17 Apr, 2020 7 commits
-
-
Sami Kyostila authored
This patch replaces V8's tracing implementation (i.e., the TRACE_EVENT macros) with the track event base implementation from Perfetto. The advantages of doing this are: 1) This allows us to remove most tracing-related backend code from V8. 2) V8 can start writing strongly typed trace event arguments, which are more compact, easier to process and more extensible than legacy JSON-based trace arguments. For the time being, we still support the old trace macros when V8 is embedded into Chrome and other embedders. Design doc: https://docs.google.com/document/d/1f7tt4cb-JcA5bQFR1oXk60ncJPpkL02_Hi_Bc6MfTQk/edit#heading=h.398p6b4eaen2 Bug: chromium:1006766 Change-Id: Ie71474fbe065821772b13d851487ebbca680c4ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947688 Commit-Queue: Sami Kyöstilä <skyostil@chromium.org> Auto-Submit: Sami Kyöstilä <skyostil@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67217}
-
Ng Zhi An authored
Bug: chromium:1071711 Bug: v8:10258 Change-Id: Id19add0c7e77ee3b834ff47274b9986cc2aa1f69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154767Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67216}
-
Jakob Kummerow authored
And a new flag --experimental-wasm-gc, which doesn't do anything yet. Bug: v8:7748 Change-Id: I927d1d90559249db3ee9f8d240775d45098e52a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154197 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67215}
-
Milad Farazmand authored
Port 3c809e0d Original Commit Message: .type directive is required on arm to enable ARM/Thumb interworking. R=mlippautz@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I5aa258033fc89dbb1165b926c3351abc45ed9d85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154836Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67214}
-
Clemens Backes authored
{StaticCharVector}, according to its name, should return a {Vector<const char>}. For getting a {Vector<const uint8_t>}, the method should be called {StaticOneByteVector}, analog to the {OneByteVector} methods that already exist. Also, {StaticCharVector} is constexpr, but {StaticOneByteVector} cannot be, since it contains a {reinterpret_cast}. The same holds for {Vector::cast} in general. This CL - changes the return type of {StaticCharVector} to be {Vector<const char>}, - introduces a new {StaticOneByteVector} which returns {Vector<const uint8_t>}, - fixes constexpr annotations at various methods returning {Vector}s, - refactors users of {StaticCharVector} to either use {StaticOneByteVector} instead, or work on {char} if that makes more sense. R=leszeks@chromium.org Bug: v8:10426 Change-Id: I71e336097e41ad30f982aa6344ca3d67b3a01fe3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154196 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67213}
-
Seth Brenith authored
Currently it's possible to hit an internal compiler error by declaring a non-extern class that doesn't extend anything. It's not very meanigful for a class to not extend from anything, so the parser should enforce this requirement. Change-Id: I38064f87345d28ce84521261bbfd33d9b1c71334 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153847 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67212}
-
Milad Farazmand authored
Change-Id: I436c779613e7ddf4b5c830807414dbc8787b89f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151103Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67211}
-