- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: Icc60fdbf247ec05f9b5688b3d2d73d4fed06ea89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2289770 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68784}
-
- 18 Jun, 2020 1 commit
-
-
Jakob Gruber authored
... in regexp bytecode {length,name} accessors and in peephole optimization. Bug: chromium:1095866 Change-Id: I78c89d35d796776b61eabf82b921f7582e431be7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250243Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68400}
-
- 12 Mar, 2020 1 commit
-
-
Iain Ireland authored
This is a grab-bag of small compatibility fixes to make it easier to import irregexp into SpiderMonkey. For changes where the commit message was longer than the change itself, it didn't seem worth opening a separate review. [regexp] Use uc16 in FilterOneByte SpiderMonkey uses char16_t instead of uint16_t for its two-byte strings. (This matches ICU. It looks like V8 considered making the same change, but decided against it: see https://bugs.chromium.org/p/v8/issues/detail?id=6487.) Fortunately, irregexp is careful about only using uc16, so SpiderMonkey can just define uc16 = char16_t and *almost* everything works out. This patch fixes the single place in irregexp where that is not true. [regexp] Remove unreachable return The return statement at the end of RegExpParser::ParseClassCharacterEscape is unreachable, because every branch of the switch returns. This triggered static analysis errors in SpiderMonkey. [regexp] Remove trivial assertion The assertion in BytecodeSequenceNode::ArgumentMapping cannot fail, because size_t is an unsigned type. This triggered static analysis warnings in SpiderMonkey. [regexp] Make RegExpStack constructor public In V8, the RegExpStack's private constructor is called from Isolate, which is a friend class. In SpiderMonkey, we use a wrapper around new to control where memory is allocated, so we need the RegExpStack constructor to be visible outside of Isolate. [regexp] Refactor Isolate::IncreaseTotalRegexpCodeGenerated The call-site of Isolate::IncreaseTotalRegexpCodeGenerated is the only place inside irregexp where HeapObject::Size is called. SpiderMonkey's heap-allocated objects live in arenas, and don't have a standardized way of finding the size. In this particular case it would be safe to hardcode a size of 0, but leaving HeapObject::Size undefined will ensure that SpiderMonkey doesn't silently do the wrong thing if somebody in V8 adds a new, more meaningful call to HeapObject::Size. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I5b81e1a261fec8c85a63f71f34cd12d68f638334 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090191 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66676}
-
- 08 Oct, 2019 1 commit
-
-
Jakob Gruber authored
Left-shifting a variable of signed type containing a negative value is undefined behavior. Bug: chromium:1010465,v8:9330 Change-Id: Ide524f87a7d76f906f6034de4c6605df150c66a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847151Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64154}
-
- 07 Oct, 2019 1 commit
-
-
Junliang Yan authored
Disable because it's not yet supported on BE Bug: v8:9330 Change-Id: Ia850801d410d3eeaccf9933dd2669f6077e2919c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1834904Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64141}
-
- 01 Oct, 2019 1 commit
-
-
Jakob Gruber authored
This is a reland of 66129430 Fixed: Unaligned reads, unspecified evaluation order. Original change's description: > [regexp] Bytecode peephole optimization > > Bytecodes used by the regular expression interpreter often occur in > specific sequences. The number of dispatches in the interpreter can be > reduced if those sequences are combined into a single bytecode. > > This CL adds a peephole optimization pass for regexp bytecodes. > This pass checks the generated bytecode for pre-defined sequences that > can be merged into a single bytecode. > > With the currently implemented bytecode sequences a speedup of 1.12x on > regex-dna and octane-regexp is achieved. > > Bug: v8:9330 > Change-Id: I827f93273a5848e5963c7e3329daeb898995d151 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743 > Commit-Queue: Patrick Thier <pthier@google.com> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63992} Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux_gcc_rel Bug: v8:9330,chromium:1008502,chromium:1008631 Change-Id: Ib9fc395b6809aa1debdb54d9fba5b7f09a235e5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1828917Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64064}
-
- 26 Sep, 2019 2 commits
-
-
Clemens Backes [né Hammacher] authored
This reverts commit 66129430. Reason for revert: Fails on gcc: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/3394 Original change's description: > [regexp] Bytecode peephole optimization > > Bytecodes used by the regular expression interpreter often occur in > specific sequences. The number of dispatches in the interpreter can be > reduced if those sequences are combined into a single bytecode. > > This CL adds a peephole optimization pass for regexp bytecodes. > This pass checks the generated bytecode for pre-defined sequences that > can be merged into a single bytecode. > > With the currently implemented bytecode sequences a speedup of 1.12x on > regex-dna and octane-regexp is achieved. > > Bug: v8:9330 > Change-Id: I827f93273a5848e5963c7e3329daeb898995d151 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743 > Commit-Queue: Patrick Thier <pthier@google.com> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63992} TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com Change-Id: Ie526fe3691f6abdd16b51979000fdafb7afce8ef No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9330 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826727Reviewed-by: Clemens Backes [né Hammacher] <clemensb@chromium.org> Commit-Queue: Clemens Backes [né Hammacher] <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#63998}
-
Patrick Thier authored
Bytecodes used by the regular expression interpreter often occur in specific sequences. The number of dispatches in the interpreter can be reduced if those sequences are combined into a single bytecode. This CL adds a peephole optimization pass for regexp bytecodes. This pass checks the generated bytecode for pre-defined sequences that can be merged into a single bytecode. With the currently implemented bytecode sequences a speedup of 1.12x on regex-dna and octane-regexp is achieved. Bug: v8:9330 Change-Id: I827f93273a5848e5963c7e3329daeb898995d151 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63992}
-