- 06 Sep, 2021 1 commit
-
-
Jakob Gruber authored
The test should be enabled once reentrancy is supported. Bug: v8:11382 Change-Id: Ifb90d8a6fd8bf9f05e9ca2405d4e04e013ce7ee3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138201 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#76667}
-
- 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 2 commits
-
-
Jakob Gruber authored
.. and decrease the include-ball size. Change-Id: Id35358a6882156f6684475b7f0b0193f8ca5eaf5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103313 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#76386}
-
Jakob Gruber authored
The JSRegExp heap object should not be the source of truth for regexp flags, which are also relevant in places that don't need or want to care about the heap object layout (e.g.: the regexp parser). Introduce RegExpFlags as a new source of truth, and base everything else on these flags. As a first change, remove the js-regexp.h dependency from the regexp parser. Other files in src/regexp/ should be updated in follow-up work. Change-Id: Id9a6706c7f09e93f743b08b647b211d0cb0b9c76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103306Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#76379}
-
- 18 Aug, 2021 1 commit
-
-
Jakob Gruber authored
.. instead of a FlatStringReader. This is in preparation for reusing the regexp parser directly from the JS parser, which uses different string types (AstRawString instead of heap Strings). Drive-by: Hide parser internals in the .cc file. Bug: v8:896 Change-Id: I06bd08f2ef5fd7a5e9812c123d88b89cacf5d864 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101488 Commit-Queue: Patrick Thier <pthier@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#76365}
-
- 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}
-
- 24 Jun, 2021 3 commits
-
-
Dan Elphick authored
This is a reland of 9701d4a4 with a small fix for some code landed in between the dry-run and submission. Original change's description: > [base] Move most of src/numbers into base > > Moves all but conversions.*, hash-seed-inl.h and math-random.* into > base, in preparation for moving the parts of conversions that don't > access HeapObjects. > > Also moves uc16 and uc32 out of commons/globals.h into base/strings.h. > > Bug: v8:11917 > Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Auto-Submit: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75354} Bug: v8:11917 Change-Id: Ie1ec9032fe56646a7c7303185cecc70fce5694ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982607Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75368}
-
Nico Hartmann authored
This reverts commit 9701d4a4. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64/40802/overview Original change's description: > [base] Move most of src/numbers into base > > Moves all but conversions.*, hash-seed-inl.h and math-random.* into > base, in preparation for moving the parts of conversions that don't > access HeapObjects. > > Also moves uc16 and uc32 out of commons/globals.h into base/strings.h. > > Bug: v8:11917 > Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Auto-Submit: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75354} Bug: v8:11917 Change-Id: Iacf796c95256016fa74f0a910c5bb1a86baa425a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982605 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#75356}
-
Dan Elphick authored
Moves all but conversions.*, hash-seed-inl.h and math-random.* into base, in preparation for moving the parts of conversions that don't access HeapObjects. Also moves uc16 and uc32 out of commons/globals.h into base/strings.h. Bug: v8:11917 Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75354}
-
- 18 Jun, 2021 1 commit
-
-
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 1 commit
-
-
Igor Sheludko authored
Bug: v8:11880 Change-Id: Idf23521d6cb1885922f92e1050937daa2d29acd7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968409Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75225}
-
- 09 Feb, 2021 1 commit
-
-
Brice Dobry authored
This very large changeset adds support for RISC-V. Bug: v8:10991 Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344 Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72598}
-
- 28 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This simplifies the logic since we can guarantee to have a Handle<String>. The removed constructor was only used in tests. Change-Id: I13519e474fe92892e9e8a39802d84cfab2c5b5ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505711 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70849}
-
- 05 Oct, 2020 1 commit
-
-
Maya Lekova authored
Bug: chromium:1130844, v8:10973 Change-Id: I912f2cf6cedaf22dd50d456622880ea266b65dcd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445509 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#70323}
-
- 21 Sep, 2020 1 commit
-
-
Martin Bidlingmaier authored
Assertions are implemented with the new ASSERTION instruction. The nfa interpreter evaluates the assertion based on the current context in the subject string every time a thread executes ASSERTION. This is analogous to what re2 and rust/regex do. Alternatives to this approach: - The interpreter could calculate eagerly for all assertion types whether they are satisfied whenever the current input position is advanced. This would make evaluating the ASSERTION instruction itself cheaper, but at the cost of making every advance in the input string more expensive. I suspect this would be slower on average because assertions are not that common that we typically evaluate >= 2 assertions at every input position. - Assertions in a regexp could be desugared into CONSUME_RANGE instructions, so that no new instruction would be necessary. For example, the word boundary assertion \b is satisfied at a given position/state if we have just consumed a word character and will consume a non-word character next, or vice-versa. The tricky part about this is that the assertion itself should not consume input, so we'd have to split (automaton) states according to whether we've arrived at them via a word character or not. The current compiler is not really equipped for this kind of transformation. For {start,end} of {line,file} assertions, we'd need to introduce dummy characters indicating start/end of input (say, 0x10000 and 0x10001) which we feed to the interpreter before respectively after the actual input. I suspect that this approach wouldn't make much of a difference for NFA execution. It would likely speed up (lazy) DFA execution though because assertions would be dealt with in the fast path. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: Ic2012c943e0ce54eb8662789fb3d4c1b6cd8d606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398644 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70026}
-
- 18 Aug, 2020 1 commit
-
-
Martin Bidlingmaier authored
This adds the new JsRegExp::Type EXPERIMENTAL, which should eventually be implemented with the algorithm based on automata. Currently the new engine deals with plain search strings only, i.e. regexps that do not contain operators or escape sequences. R=jgruber@chromium.org Bug: v8:10765 Change-Id: I6a10d9cdf4605d219dbe7cc1989df3bfa7349ff8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339094Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69442}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
With the new Turbofan variants (NCI and Turboprop), we need a way to distinguish between them both during and after compilation. We initially introduced CompilationTarget to track the variant during compilation, but decided to reuse the code kind as the canonical spot to store this information instead. Why? Because it is an established mechanism, already available in most of the necessary spots (inside the pipeline, on Code objects, in profiling traces). This CL removes CompilationTarget and adds a new NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine various things about a given code kind (e.g.: does this code kind deopt?). As a (very large) drive-by, refactor both Code::Kind and AbstractCode::Kind into a new CodeKind enum class. Bug: v8:8888 Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 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}
-
- 03 Jun, 2020 1 commit
-
-
Iain Ireland authored
https://crrev.com/c/2072858 rewrote the implementation of non-unicode ignore-case matches to comply with the JS spec in some corner cases. It fixed character matches and character class matches. We missed a similar bug in the implementation of back references. This CL fixes that bug. The main change is in regexp-macro-assembler.cc, where CaseInsensitiveCompareUC16 is split into CaseInsensitiveCompareUnicode (which has the same semantics as before) and CaseInsensitiveCompareNonUnicode (which has the semantics described here: https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch). Most of the rest of the patch undoes https://crrev.com/c/2081816 to once again make the unicode flag available to the macroassembler, so that we can decide which helper function to call. The testcase is a version of test/intl/regress-10248.js, modified to test backreferences. Bug: v8:10573 Change-Id: I70ef7d134d37f99b1f75a5eba17020e82d59f1b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219284Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68129}
-
- 30 Apr, 2020 1 commit
-
-
Zhao Jiazhong authored
The UnicodePropertyEscapeCodeSize test set the max code size as 150KB, which is too strict for mips64. This CL loosen the limit to 200KB. Bug: v8:10441 Change-Id: I8532d4d51eedd7713075d86e84c52a58d2412861 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172927Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#67489}
-
- 29 Apr, 2020 1 commit
-
-
Jakob Gruber authored
This is a reland of 6a0e7224 Original change's description: > [regexp] Limit the size of inlined choice nodes > > Codegen for unicode property escapes (e.g.: /\p{L}/u) can produce huge > code objects. This effect can be further magnified through inlining, > leading to exponential code growth in the size of the pattern. > > This CL is a (fairly hacky) way to avoid exponential growth. We > recognize choice nodes with 'many' choices and disable inlining for > them. In the future we should fix this properly, either by using the > code size budget correctly, or by improving codegen for property > escapes. > > Bug: v8:10441 > Change-Id: I817f145251ec8b1b9906cc735c9e9bdb004c98ed > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170229 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67433} Tbr: yangguo@chromium.org Bug: v8:10441 Change-Id: I9a16cc9e8248cb46d3d16a4e2d250968cc1b7b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172679Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67462}
-
- 28 Apr, 2020 2 commits
-
-
Clemens Backes authored
This reverts commit 6a0e7224. Reason for revert: Fails noi18n: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/31513 Original change's description: > [regexp] Limit the size of inlined choice nodes > > Codegen for unicode property escapes (e.g.: /\p{L}/u) can produce huge > code objects. This effect can be further magnified through inlining, > leading to exponential code growth in the size of the pattern. > > This CL is a (fairly hacky) way to avoid exponential growth. We > recognize choice nodes with 'many' choices and disable inlining for > them. In the future we should fix this properly, either by using the > code size budget correctly, or by improving codegen for property > escapes. > > Bug: v8:10441 > Change-Id: I817f145251ec8b1b9906cc735c9e9bdb004c98ed > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170229 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67433} TBR=yangguo@chromium.org,jgruber@chromium.org Change-Id: I503b8b2be539468d86e4ec1ac13074cd1c06a5cb No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10441 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2169101Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67436}
-
Jakob Gruber authored
Codegen for unicode property escapes (e.g.: /\p{L}/u) can produce huge code objects. This effect can be further magnified through inlining, leading to exponential code growth in the size of the pattern. This CL is a (fairly hacky) way to avoid exponential growth. We recognize choice nodes with 'many' choices and disable inlining for them. In the future we should fix this properly, either by using the code size budget correctly, or by improving codegen for property escapes. Bug: v8:10441 Change-Id: I817f145251ec8b1b9906cc735c9e9bdb004c98ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170229 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67433}
-
- 21 Apr, 2020 1 commit
-
-
Jakob Gruber authored
... between the interpreter and generated code. Prior to this CL, pre- and post conditions on the output register array differed between the interpreter and generated code. Interpreter Pre: `output` fits captures and temporary registers. Post: None. Generated code Pre: `output` fits capture registers. Post: `output` is modified if and only if the match succeeded. This CL changes the interpreter to match generated code pre- and post conditions by allocating space for temporary registers inside the interpreter. Drive-by: Add MaxRegisterCount, RegistersForCaptureCount helpers. Bug: chromium:1067270 Change-Id: I2900ef2f31207d817ec7ead3e0e2215b23b398f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135642 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67268}
-
- 19 Mar, 2020 3 commits
-
-
Iain Ireland authored
This is a reland of e80ca24c Original change's description: > [regexp] Rewrite error handling > > This patch modifies irregexp's error handling. Instead of representing > errors as C strings, they are represented as an enumeration value > (RegExpError), and only converted to strings when throwing the error > object in regexp.cc. This makes it significantly easier to integrate > into SpiderMonkey. A few notes: > > 1. Depending on whether the stack overflows during parsing or > analysis, the stack overflow message can vary ("Stack overflow" or > "Maximum call stack size exceeded"). I kept that behaviour in this > patch, under the assumption that stack overflow messages are > (sadly) the sorts of things that real world code ends up depending > on. > > 2. Depending on the point in code where the error was identified, > invalid unicode escapes could be reported as "Invalid Unicode > escape", "Invalid unicode escape", or "Invalid Unicode escape > sequence". I fervently hope that nobody depends on the specific > wording of a syntax error, so I standardized on the first one. (It > was both the most common, and the most consistent with other > "Invalid X escape" messages.) > > 3. In addition to changing the representation, this patch also adds an > error_pos field to RegExpParser and RegExpCompileData, which stores > the position at which an error occurred. This is used by > SpiderMonkey to provide more helpful messages about where a syntax > error occurred in large regular expressions. > > 4. This model is closer to V8's existing MessageTemplate > infrastructure. I considered trying to integrate it more closely > with MessageTemplate, but since one of our stated goals for this > project was to make it easier to use irregexp outside of V8, I > decided to hold off. > > R=jgruber@chromium.org > > Bug: v8:10303 > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66784} R=jgruber@chromium.org Bug: v8:10303 Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66798}
-
Leszek Swirski authored
This reverts commit e80ca24c. Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679) Original change's description: > [regexp] Rewrite error handling > > This patch modifies irregexp's error handling. Instead of representing > errors as C strings, they are represented as an enumeration value > (RegExpError), and only converted to strings when throwing the error > object in regexp.cc. This makes it significantly easier to integrate > into SpiderMonkey. A few notes: > > 1. Depending on whether the stack overflows during parsing or > analysis, the stack overflow message can vary ("Stack overflow" or > "Maximum call stack size exceeded"). I kept that behaviour in this > patch, under the assumption that stack overflow messages are > (sadly) the sorts of things that real world code ends up depending > on. > > 2. Depending on the point in code where the error was identified, > invalid unicode escapes could be reported as "Invalid Unicode > escape", "Invalid unicode escape", or "Invalid Unicode escape > sequence". I fervently hope that nobody depends on the specific > wording of a syntax error, so I standardized on the first one. (It > was both the most common, and the most consistent with other > "Invalid X escape" messages.) > > 3. In addition to changing the representation, this patch also adds an > error_pos field to RegExpParser and RegExpCompileData, which stores > the position at which an error occurred. This is used by > SpiderMonkey to provide more helpful messages about where a syntax > error occurred in large regular expressions. > > 4. This model is closer to V8's existing MessageTemplate > infrastructure. I considered trying to integrate it more closely > with MessageTemplate, but since one of our stated goals for this > project was to make it easier to use irregexp outside of V8, I > decided to hold off. > > R=jgruber@chromium.org > > Bug: v8:10303 > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66784} TBR=jgruber@chromium.org,iireland@mozilla.com Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10303 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66786}
-
Iain Ireland authored
This patch modifies irregexp's error handling. Instead of representing errors as C strings, they are represented as an enumeration value (RegExpError), and only converted to strings when throwing the error object in regexp.cc. This makes it significantly easier to integrate into SpiderMonkey. A few notes: 1. Depending on whether the stack overflows during parsing or analysis, the stack overflow message can vary ("Stack overflow" or "Maximum call stack size exceeded"). I kept that behaviour in this patch, under the assumption that stack overflow messages are (sadly) the sorts of things that real world code ends up depending on. 2. Depending on the point in code where the error was identified, invalid unicode escapes could be reported as "Invalid Unicode escape", "Invalid unicode escape", or "Invalid Unicode escape sequence". I fervently hope that nobody depends on the specific wording of a syntax error, so I standardized on the first one. (It was both the most common, and the most consistent with other "Invalid X escape" messages.) 3. In addition to changing the representation, this patch also adds an error_pos field to RegExpParser and RegExpCompileData, which stores the position at which an error occurred. This is used by SpiderMonkey to provide more helpful messages about where a syntax error occurred in large regular expressions. 4. This model is closer to V8's existing MessageTemplate infrastructure. I considered trying to integrate it more closely with MessageTemplate, but since one of our stated goals for this project was to make it easier to use irregexp outside of V8, I decided to hold off. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66784}
-
- 17 Mar, 2020 1 commit
-
-
Georgia Kouveli authored
Generate a BTI instruction at each target of an indirect branch (BR/BLR). An indirect branch that doesn't jump to a BTI instruction will generate an exception on a BTI-enabled core. On cores that do not support the BTI extension, the BTI instruction is a NOP. Targets of indirect branch instructions include, among other things, function entrypoints, exception handlers and jump tables. Lazy deopt exits can potentially be reached through an indirect branch when an exception is thrown, so they also get an additional BTI instruction. Bug: v8:10026 Change-Id: I0ebf51071f1b604f60f524096e013dfd64fcd7ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967315 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66751}
-
- 02 Mar, 2020 1 commit
-
-
Jakob Gruber authored
In the past we've used the isolate argument to signal whether we were in unicode mode (nullptr) or not (the real isolate). This is no longer needed, and in fact breaks no-i18n mode which always expects to have a real isolate. Bug: v8:10120 Change-Id: I2f848c4ff8c2ff0e9b84278cbcdf3c3670e44e58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081816Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66520}
-
- 21 Feb, 2020 1 commit
-
-
Wouter Vermeiren authored
After support for ARCH_PPC was dropped, it became a subset of ARCH_PPC64. If you compile for ppc64, then you set the ARCH_PPC64 define which also sets the ARCH_PPC define. To be able to again support ppc (32 bit) those defines should be split up again. This commit only splits up the defines but does not introduce a working ARCH_PPC variant. Bug: v8:10102 Change-Id: I64e0749f8e5a7dc078ee7890d92e57b82706a849 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989826 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66390}
-
- 21 Oct, 2019 1 commit
-
-
Jakob Gruber authored
V8 uses a backtracking regexp engine, which has the caveat that some regexp patterns can have exponential runtime behavior when excessive backtracking is involved. Especially when regexp patterns are user-controlled, it would be useful to be able to set an upper limit for a single regexp execution. This CL takes an initial step in that direction by adding a backtracking limit (intended to approximate execution time): - The limit is stored in the JSRegExp's data array. - A limit can currently only be set through the %NewRegExpWithLimit runtime function. - The limit is applied during interpreter execution. When exceeded, the interpreter stops execution and returns FAILURE (even if continued execution would at some later point have resulted in SUCCESS). In follow-up CLs, this mechanism will be extended to work in jitted regexp code, and exposed through the V8 API. Bug: v8:9695 Change-Id: Iadb5c100052f4a63b26f1ec49cf97c6713a66b9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864934 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64417}
-
- 07 Oct, 2019 1 commit
-
-
Mathias Bynens authored
We've gathered sufficient data, so the use counter can now be removed again. The use counter was originally added here: - V8 CL: https://chromium-review.googlesource.com/c/v8/v8/+/1718145 - Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/1718367 The Chromium plumbing was removed here: https://chromium-review.googlesource.com/c/chromium/src/+/1839851 BUG=v8:9551 Change-Id: I829a0fe34d9ebade1403cb4d1c0b9c997f125074 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844774Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#64124}
-
- 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}
-
- 29 Aug, 2019 1 commit
-
-
Patrick Thier authored
The code fields in a JSRegExp object now either contain irregexp compiled code or a trampoline to the interpreter. This way the code can be executed without explicitly checking if the regexp shall be interpreted or executed natively. In case of interpreted regexp the generated bytecode is now stored in its own fields instead of the code fields for Latin1 and UC16 respectively. The signatures of the jitted irregexp match and the regexp interpreter have been equalized. Bug: v8:9516 Change-Id: I30e3d86f4702a902d3387bccc1ee91dea501fe4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762513 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63457}
-
- 12 Aug, 2019 1 commit
-
-
Ana Peško authored
This CL implements a naive tiering-up strategy where the interpreter is used for the first execution for every regex, and the compiler is used for every execution after that. The only exception is if a global replace is being executed on a regex, we eagerly tier-up to native code right away. To use the tier-up logic --regexp-tier-up needs to be set. It is currently disabled by default. Bug v8:9566 Change-Id: Ib64ed77cbfcde10411161c0541dfa2501a0a93bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710661Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ana Pesko <anapesko@google.com> Cr-Commit-Position: refs/heads/master@{#63150}
-