- 24 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Add a CompareCharsEqual to complement CompareChars, where we only care about equality and not ordering. For such cases, we can memcmp for two- byte as well as one-byte strings (we can't for CompareChars because the ordering would be incorrect on little-endian systems). Replace uses of CompareChars that only compare the result against zero, with CompareCharsEqual. Additionally, use some template magic to simplify the "make unsigned" operation in these methods. Change-Id: I0d65bee81b98d3938d15daa4af331c90558ea84f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557980 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71385}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 09 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I8deefa9cf5ac10b769e4ebb7029a82957cf669c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2525540Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71029}
-
- 14 Oct, 2020 1 commit
-
-
Martin Bidlingmaier authored
We fall back from irregexp to the experimental engine if a backtrack limit is exceeded and the experimental engine can handle the regexp. The feature can be turned on with a boolean flag, and an uint-valued flag controls the default backtrack limit. For regexps that are constructed with an explicit backtrack limit (API, %NewRegExpWithBacktrackLimit), we choose the lower of the explicit and default backtrack limits. The default backtrack limit does not apply to regexps that can't be handled by the experimental engine, and for such regexps an explicitly specified backtrack limit is handled as before by returning null if we exceed it. Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Bug: v8:10765 Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341 Commit-Queue: Martin Bidlingmaier <mbid@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70500}
-
- 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}
-
- 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}
-
- 20 May, 2020 1 commit
-
-
Jakob Gruber authored
This was introduced by https://crrev.com/c/2207137. Load offsets can be negative. Drive-by: Add a helper function to wrap the verbose static casts in bounds checks. Bug: chromium:1084872,chromium:1083450 Change-Id: I48934d04a8ab15a8fc347465064b190e32c00716 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209066 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67924}
-
- 19 May, 2020 2 commits
-
-
Jakob Gruber authored
So far this is mainly a readability improvement to specify expectations on the packed argument. In the future we should also check signedness during bytecode generation. Drive-by: Update DCHECK to allow signed args to CHECK_CURRENT_POSITION. Bug: chromium:1083450 Change-Id: I9376ec691b51eb251c972309ad65dd6c04eec3ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207137 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67880}
-
Jakob Gruber authored
Verify that `current` always points inside, or just past the end of the subject string. Bug: chromium:1083450 Change-Id: I27ba49cbfd0aa93cd2e305efafc23b155c98a49b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207136Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67879}
-
- 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}
-
- 06 Apr, 2020 1 commit
-
-
Jakob Gruber authored
This is a minimal version of https://crrev.com/c/2135642 intended for backmerges. Ensure that the interpreter has space for all required registers. Bug: chromium:1067270 Change-Id: Iefd016b4845fb8698d1e0ef5f6a03df0e66aa576 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137403 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67013}
-
- 17 Mar, 2020 1 commit
-
-
Iain Ireland authored
Some code at the interface between irregexp and the rest of V8 uses V8-specific APIs that are not used elsewhere in irregexp. For example, only a handful of functions in irregexp call or are called from generated code. When embedding irregexp into SpiderMonkey, these functions are an obstacle, because they are dead code, but still have to compile. To simplify the process of embedding, this patch does two things: 1. It moves StringCharacterPosition out of irregexp and into objects/string, renaming it "AddressOfCharacterAt". 2. It guards the following set of functions with '#ifndef COMPILING_IRREGEXP_FOR_EXTERNAL_EMBEDDER': - IrregexpInterpreter::MatchForCallFromJs - NativeRegExpMacroAssembler::CheckStackGuardState - NativeRegExpMacroAssembler::Match - NativeRegExpMacroAssembler::Execute This will have no effect in a V8 build, but can be defined by SpiderMonkey or another embedder to omit the problematic functions. In the future, if we attempt to make a cleaner separation between V8 and irregexp, these functions will be a good place to start defining the API boundary. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I9f531a36e4f13440cafb0d0ade921f4c09f39c05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097220Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66750}
-
- 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}
-
- 16 Jan, 2020 1 commit
-
-
Jakob Gruber authored
The advance-by parameter can contain negative numbers, but until this CL was treated as unsigned. Bug: v8:10072,v8:9330 Change-Id: Ib9a9c2d47ba71fa819e89502d14871af6dfc9693 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002543 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#65809}
-
- 22 Oct, 2019 1 commit
-
-
Jakob Gruber authored
The new regexp_backtracks / V8.RegExpBacktracks counter tracks the number of backtracks performed per regexp execution. The results can help us prioritize related work. Note that we only count backtracks in the interpreter. Jitted code is ignored. With our current regexp tiering strategy, that means we count backtracks only in the first execution of each regexp. Chromium CL: https://crrev.com/c/1871601 Bug: v8:9892 Change-Id: I19146d6e9bc2355f210a050e93dd7e856ab066f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873696 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64467}
-
- 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}
-
- 10 Oct, 2019 1 commit
-
-
Jakob Gruber authored
The tier-up check is only needed for instances that currently go through the interpreter. It is simpler to move the check into the interpreter's C++ entry point. At that point, when we see a JSRegExp that should tier-up, we simply return RETRY which will automatically send us back into runtime where the actual recompilation happens. Bug: v8:9566 Change-Id: Ib7bb5d21a30bae45d6e14846edd2a47469989b35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852125 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64210}
-
- 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}
-
- 24 Sep, 2019 1 commit
-
-
Jakob Gruber authored
This introduces a limit for the interpreter's BacktrackStack to match the limit used by generated code (RegExpStack::kMaximumStackSize). Bug: chromium:1006670 Change-Id: I0b7613698e61257aecca89535ad9109c7e454692 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1821458 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63945}
-
- 12 Sep, 2019 1 commit
-
-
Patrick Thier authored
Currently the dispatch table could be accessed out of bounds if something is wrong with the generated bytecode. OOB access of the dispatch table can lead to jumps to arbitrary addresses in the code space. This CL prevents this issue by changing the following: BYTECODE_MASK now filters out all bits not currently used for bytecodes. All unused slots between the last actually defined bytecode and BYTECODE_MASK are now filled with BREAK Bytecodes (invalid operation). This way we can not access out of bounds of the dispatch table if something is broken/tampered with, preventing jumps to arbitrary code. Bug: v8:9699 Change-Id: Ibce591ae94b52472ba74a9fd0666e55185af7b2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795349 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63708}
-
- 09 Sep, 2019 1 commit
-
-
Ana Peško authored
This CL implements the tier-up strategy where the interpreter can be used for an arbitrary number of executions for every regex, before tiering-up to the compiler. The only exception is for functional global replaces, where we eagerly tier-up to native code right away. To use the tier-up logic --regexp-tier-up=value needs to be set. It is currently set to 0 by default. Change-Id: I770857e5eae710a952fe47661cb42957c53848b4 Bug: v8:9566 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789299 Commit-Queue: Ana Pesko <anapesko@google.com> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63623}
-
- 29 Aug, 2019 3 commits
-
-
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}
-
Jakob Gruber authored
Similar to CheckNotAtStart, one can now apply an offset to the CheckAtStart operation. Due to a recent change, all callsites of CheckNotAtStart now need to pass an offset, whereas previously the offset was just assumed to be zero. Bug: chromium:996391 Change-Id: Ia59a584e93e5384479f05abddef7859b420b023a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773272 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63444}
-
Jakob Gruber authored
Printing regexp code used to behind the generic --print-code flag, but there was no way to distinguish between irregexp-generated code; and printing regexp bytecode was not supported at all (the --trace-regexp-bytecodes flag *did* exist, but prints the execution trace at runtime and not the generated bytecode sequence). This CL adds two new flags: --print-regexp-code --print-regexp-bytecode Regexp code is no longer printed as part of --print-code. Example output for --print-regexp-bytecode: generated bytecode for regexp pattern: .(?<!^.) 0x1ddcc614cbd0 0 PUSH_BT, 02, 00, 00, 00, c0, 00, 00, 00 ....... 0x1ddcc614cbd8 8 LOAD_CURRENT_CHAR, 11, 00, 00, 00, b0, 00, 00, 00 ....... 0x1ddcc614cbe0 10 CHECK_CHAR, 18, 0a, 00, 00, b0, 00, 00, 00 ....... 0x1ddcc614cbe8 18 CHECK_CHAR, 18, 0d, 00, 00, b0, 00, 00, 00 ....... 0x1ddcc614cbf0 20 PUSH_CP, 01, 00, 00, 00 ... Bug: chromium:996391 Change-Id: I731defbd7cf9ed29753a39bb1d7205dc136ca950 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773249 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63442}
-
- 13 Aug, 2019 1 commit
-
-
Patrick Thier authored
When GC triggered while an exception is pending, a read to memory that was no longer valid could happen while backtracking in the regexp interpreter (introduced with commit fb0df2c8). This CL prevents this dirty read, that could have been a security issue. Bug: chromium:992389, v8:9575 Change-Id: Ie1acd6faa16665e211666c6a8dcf2a9d74e0c886 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751342 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63195}
-
- 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}
-
- 08 Aug, 2019 1 commit
-
-
Patrick Thier authored
This CL changes the dispatch technique in the regex interpreter to token-threaded dispatch, if computed gotos are supported by the compiler. Otherwise old switch-based dispatch is still used (e.g. for MSVC). With computed gotos, less jumps will be emitted (no extra jump to single branch point/begin of switch) and branch prediction will be better because of no single branch point. This CL improves performance on the RexBench Benchmark suite by ~10%. Bug: v8:9575 Change-Id: I585ad824ff1cc595a5dfa8831ad66d6810d0119b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733073Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Patrick Thier <pthier@google.com> Cr-Commit-Position: refs/heads/master@{#63126}
-
- 26 Jul, 2019 1 commit
-
-
Seth Brenith authored
This change updates the RegExp bytecode generator to emit checks for larger eats_at_least values when they are available, so we can fail to match earlier in some cases. Bug: v8:9305 Change-Id: I96740531e142ff8dced41c49b774845b07df6ae6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709768 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62942}
-
- 24 Jul, 2019 1 commit
-
-
Patrick Thier authored
This is a reland of c2ee4a79 Original change's description: > Reland "[regexp] Call the regexp interpreter without CEntry overhead" > > This is a reland of d4d28b73 > > Original change's description: > > [regexp] Call the regexp interpreter without CEntry overhead > > > > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set. > > > > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call). > > > > Bug: v8:8954 > > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391 > > Commit-Queue: Patrick Thier <pthier@google.com> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#62753} > > Bug: v8:8954 > Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Patrick Thier <pthier@google.com> > Cr-Commit-Position: refs/heads/master@{#62794} Bug: v8:8954 Change-Id: Ice77c05240f1fabd36bf97b8e789dd4c25a9718f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715451Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62904}
-
- 19 Jul, 2019 1 commit
-
-
Sathya Gunasekaran authored
This reverts commit c2ee4a79. Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9) See https://bugs.chromium.org/p/chromium/issues/detail?id=985624 Original change's description: > Reland "[regexp] Call the regexp interpreter without CEntry overhead" > > This is a reland of d4d28b73 > > Original change's description: > > [regexp] Call the regexp interpreter without CEntry overhead > > > > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set. > > > > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call). > > > > Bug: v8:8954 > > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391 > > Commit-Queue: Patrick Thier <pthier@google.com> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#62753} > > Bug: v8:8954 > Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Patrick Thier <pthier@google.com> > Cr-Commit-Position: refs/heads/master@{#62794} TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:8954, chromium:985624 Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62824}
-
- 18 Jul, 2019 1 commit
-
-
Patrick Thier authored
This is a reland of d4d28b73 Original change's description: > [regexp] Call the regexp interpreter without CEntry overhead > > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set. > > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call). > > Bug: v8:8954 > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391 > Commit-Queue: Patrick Thier <pthier@google.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62753} Bug: v8:8954 Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@google.com> Cr-Commit-Position: refs/heads/master@{#62794}
-
- 17 Jul, 2019 2 commits
-
-
Sathya Gunasekaran authored
This reverts commit d4d28b73. Reason for revert: breaks TSAN bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/9526 Original change's description: > [regexp] Call the regexp interpreter without CEntry overhead > > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set. > > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call). > > Bug: v8:8954 > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391 > Commit-Queue: Patrick Thier <pthier@google.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62753} TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com Change-Id: I3257220c4359a3b801dd80e0eff6c4534d8badee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8954 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706050Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62757}
-
Patrick Thier authored
Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set. This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call). Bug: v8:8954 Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62753}
-
- 18 Jun, 2019 1 commit
-
-
Jakob Gruber authored
This CL renames jsregexp.{h,cc} to regexp.{h,cc}, hides all non-public functions of RegExpImpl in the .cc file, and renames the public parts of RegExpImpl to just RegExp. Include directives from outside the src/regexp directory are limited to regexp.h, regexp-stack.h, and regexp-utils.h. We also expose all result codes that can be returned by irregexp code (including RETRY) on the public header since they are needed elsewhere, e.g. in builtins. Bug: v8:9359 Change-Id: Iae1a01ac9f6e1e4dc168f3fbe8fe8679cb6b1259 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662297Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62240}
-
- 12 Jun, 2019 1 commit
-
-
Jakob Gruber authored
bytecodes-irregexp.h -> regexp-bytecodes.h interpreter-irregexp.{cc,h} -> regexp-interpreter.{cc,h} Change-Id: I98ca9d5c3264ad0adbd280b93082aa3e01b45b67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655294 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62113}
-
- 06 Jun, 2019 1 commit
-
-
Jakob Gruber authored
Ideally, in the common case the backtracking stack should be stack-allocated (and thus cheap). We should only switch to dynamic allocation if needed. SmallVector implements exactly this strategy, so switch to that as a backing store. This improves Octane/RegExp scores (--regexp-interpret-all) by 50%. Bug: v8:7777,v8:9330 Change-Id: I0d1b07bd8fd94483128e021390d054f483076f8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645318 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62013}
-
- 05 Jun, 2019 1 commit
-
-
Jakob Gruber authored
During regexp execution we usually do not expect any interrupts to exist. This optimization doubles Octane/RegExp scores with --regexp-interpret-all. Drive-by: Do the same for irregexp stack checks (only applicable when called through the runtime). Drive-by: Slightly more specific AllowHeapAllocation scopes. Bug: v8:7777, v8:9328, v8:9330 Change-Id: I502d54d49a1267dee4b8a086dc6c2dca318a2d97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645313 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62000}
-
- 29 May, 2019 1 commit
-
-
Jakob Gruber authored
The backtracking stack (which is actually a generic stack) used to be statically sized. At 10k elements, it was fairly large, but still easy to overflow on large subject strings. This CL changes it to a std::vector-based implementation instead which grows on-demand. Drive-by: Add braces to the BYTECODE cases to make clang-format produce a nicer output. Bug: v8:8776 Change-Id: If41a444fe3d05f6d5be1be019129788a86e6118b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634914Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61912}
-