- 22 Mar, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/192f1d2..b53200e Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/cc4989c..39af23e Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/5416b3a..befc299 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I611df71694bae2f0450ca2de2cbcc8a4916b45b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2114102Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66817}
-
- 21 Mar, 2020 2 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9e8017c..192f1d2 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/df670f0..cc4989c Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/464e9ff..5416b3a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/689fb3d..105a846 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Id8ed92bec0bdf65f55b78e92a65e281b73d0f677 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113103Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66816}
-
Johannes Henkel authored
New Rev: b7cda08cd6e522df2159413ba5f29d2a953cc1c4 Upstream Review: "Drop redundant std::move in inspector_protocol." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2112636 Change-Id: If7832adf00f1c574960e5ca3c179e7b03255fc86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113132 Auto-Submit: Johannes Henkel <johannes@chromium.org> Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#66815}
-
- 20 Mar, 2020 15 commits
-
-
Milad Farazmand authored
Port a447a44f Original Commit Message: Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I5bec2212d040801d67426a8639d20fe96035d813 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111832Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66814}
-
Johannes Henkel authored
Upstream PR: "Introduce a crdtp/dispatch.{h,cc} library." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1974680 "For the shallow parse of a DevTools message, allow "params": null." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2109466 New Revision: c69cdc36200992d21a17bf4e5c2f3a95b8860ddf Change-Id: Icc447ff9ce408b24f5245c643dd2f1843da9255f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076215 Commit-Queue: Johannes Henkel <johannes@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#66813}
-
Ng Zhi An authored
Introduces a new macro BUILD_V (v is for vector) that pushes bytes into a vector (instead of directly in an array initializer, see BUILD). This has the positive effect of being able to handle opcodes of multiple bytes (e.g. SIMD opcodes bigger that 0xfd80). Because of this "API" change, our helper macros in test-run-wasm-simd.cc and wasm-run-utils.h need to change too. So, we introduce new macros (suffixed by _V), that will call the appropriate lambdas defined in BUILD_V, that knows how to push bytes into the vector, and also can handle multi-byte opcodes. This design has a bit of duplication and ugliness, but was chosen to reduce the impact of existing tests. No restructuring of test code is required, we only need to add suffix _V. Note that we do not have multi-byte opcodes yet (in wasm-opcodes.h), this change will be breaking, and requires all the tests to be updated to use _V macros first. Bug: v8:10258 Change-Id: I86638a548fe2f9714c1cfb3bd691fb7b49bfd652 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107650 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66812}
-
Santiago Aboy Solanes authored
Now that it is implicit in function entry and loop iteration, there is no need for an explicit bytecode. Also updated tests that used explicit bytecodes. Bug: v8:10149, v8:9960 Change-Id: I3ca582f276829bd54feb35e6d4ea656a32efbd54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093507Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66811}
-
Andreas Haas authored
This CL provides a generic way to prepare a builtin call: The {PrepareBuiltinCall} takes the builtin signature for 64-bit systems, the CallDescriptor, and a Vector of VarStates for the parameters, and moves all parameters to their correct place, which is either in a register or on the stack. To test the new code this CL adjusts the implementation of AtomicWait to use PrepareBuiltinCall. Thereby AtomicWait is now also supported on 32-bit platforms, including ia32. R=clemensb@chromium.org Bug: v8:10108, v8:10281 Change-Id: Ia8589166310ea2e8442531b4ed20db62d7b4aff0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108554 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66810}
-
Santiago Aboy Solanes authored
Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. Bug: v8:10149, v8:9960 Fixes: v8:10149 Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66809}
-
Victor Gomes authored
Bug: v8:10201 Change-Id: I72cbe15912395b9b06ffdccce935abae6e7a050e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093508Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66808}
-
Leszek Swirski authored
Squash a couple of remaining places where compilation finalization was allocating new-space objects. Bug: chromium:1011762 Change-Id: Ie0462eed422016f860146724a06dd2f1963bd88e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110019 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66807}
-
Yolanda Chen authored
When spill a range without register uses inside a loop, it is beneficial to spill the range ealier at the loop header to reduce memory moves from the back edges. The changes to FindOptimalSpillingPos are motivated as follows: - Change “next_use->pos() < pos” to “next_use->pos() <= pos”. The former version causes a crash of mksnapshot in debug build, because it is possible that a UsePosition at a split point gets split to the previous range according to “DetachAt”. For example, we have a live range with: UseIntervals: [1, 20[ UsePosition: 10 When split the live range at position 10, we will get: Range 0:0: UseInterval: [1, 10[ UsePosition: 10 Range 0:1: UseInterval: [10, 20[ - Change “NextUsePositionRegisterIsBenefitial” to “NextRegisterPosition”, because there’s always a “Define” use position at the loop header for those phis that do not require a register. Using the original check will hence not apply the optimization. Change-Id: I3b0bb3687ba572f1d3fc1892cefae7e866d99baa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094964Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Yolanda Chen <yolanda.chen@intel.com> Cr-Commit-Position: refs/heads/master@{#66806}
-
Leszek Swirski authored
Ensure that the off-thread pages' marking bits (including the page headers) are correct, and synchronised correctly on merge. Bug: chromium:1011762 Change-Id: I46c66fb35d49d39eb0da3513c869baf49c366706 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110020 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66805}
-
Zhao Jiazhong authored
The FpRegister size was miswritten as kSimd128Size like x64, while it should be kDoubleSize on mips. Change-Id: Iac4c5687e398a87ec0508fb99042a487c41ddf8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110891 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#66804}
-
Georg Neis authored
I'm unable to produce an issue with this test locally, so let's try to enable it again. Big: v8:6587 Change-Id: Ida834ac4ccf8c25d8f5c1e09fc57479db46a1873 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108722 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66803}
-
Maya Lekova authored
This is patching 560f2d8b for a failing android-binary-size bot, see https://chromium-review.googlesource.com/c/chromium/src/+/2110413 TBR=rmcilroy@chromium.org Bug: chromium:747064 Change-Id: I37c5484afa427420d7a4614300556f7a5e99b21d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111211Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66802}
-
Georg Neis authored
Bug: chromium:1062916 Change-Id: Ic29ca849fb17c1409cc11018fdbc9d3363ebd55c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110027 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66801}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9b1394c..9e8017c Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8413a03..df670f0 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/6e39ba4..689fb3d TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: If6421082ec9f3e737d9892778cffec143136cbcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111138Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66800}
-
- 19 Mar, 2020 19 commits
-
-
Ng Zhi An authored
The src register needs to be different from the temporary Simd128 register since in the codegen we modify tmp before using tmp and src. Bug: chromium:1063006 Change-Id: I8b4b2d23d8f090ea37041e82cac97470bcf0d833 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111110Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66799}
-
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}
-
Andreas Haas authored
This CL introduces a CSA builtin for the TableCopy instruction. This builtin allows to generate smaller code for both TurboFan and Liftoff, and easier code generation from Liftoff. The smaller code size comes from: * Parameters are passed through registers, not the stack. * Lower number of parameters: the call target, number of parameters, and context are not passed as parameters. * No int to smi conversion in generated code. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I4734b94c8a2aff08a5938504e3e36d0d2424f8ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110010 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66797}
-
Peter Marshall authored
Chrome uses the new version now. Bug: v8:8116 Change-Id: I59af8d2c6a897a852acd6de3a7938a4b8d3943e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110015Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#66796}
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: Ica1cb36e7e071e5755009d57a0f03080b74bbf8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108743Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66795}
-
David Manouchehri authored
Bug: chromium:1062763 Change-Id: I70d44f2db06b5ec1d84ab6678582dfc559d47e7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108729 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Auto-Submit: David Manouchehri <david@davidmanouchehri.com> Cr-Commit-Position: refs/heads/master@{#66794}
-
Ng Zhi An authored
Implement i8x16.bitmask, i16x8.bitmask, i32x4.bitmask on interpreter and arm64. These operations are behind wasm_simd_post_mvp flag, as we are only prototyping to evaluate performance. The codegen is based on guidance at https://github.com/WebAssembly/simd/pull/201. Bug: v8:10308 Change-Id: I835aa8a23e677a00ee7897c1c31a028850e238a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099451Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66793}
-
Andreas Haas authored
This CL introduces a CSA builtin for the TableInit instruction. This builtin allows to generate smaller code for both TurboFan and Liftoff, and easier code generation from Liftoff. The smaller code size comes from: * Parameters are passed through registers, not the stack. * Lower number of parameters: the call target, number of parameters, and context are not passed as parameters. * No int to smi conversion in generated code. The CL also introduces a small CSA function which takes an uint32 value and a max value as parameters and returns a Smi of the minimum of these two. R=clemensb@chromium.org, ishell@chromium.org Bug: v8:10281 Change-Id: I40f248c20ec76e6ae9483a5e2907a68f42f2cb04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106201 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66792}
-
Clemens Backes authored
Add some more code comments for code snippets that are not obvious, especially if debug code is enabled. The comments help when looking at Liftoff code for debugging code generation issues. R=thibaudm@chromium.org Change-Id: I566bf2b05a454fb8addc030359969d36cb2cb707 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108557Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66791}
-
Clemens Backes authored
1) Replace a condition by a DCHECK. 2) Remove dead argument. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: I546d18e7e5520630ab32b4f73f9fe12b0441cb95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108556Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66790}
-
Clemens Backes authored
Update the "hook on function call" flag also in the wasm case, and slightly change the {IsStepping} logic to stop in any frame if the last step action was anything other than StepNext. In future CLs, this has to be extended further for StepOut and for StepOver at a return location. When that is done, we can also reenable more stepping in the test. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: Ib3aa8c2c2e137690140e5879a33e2bcc340821e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108035 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66789}
-
Daniel Bevenius authored
Currently, when GeneratePrintDefinitionsForClass generates its Print functions it uses a string literal as the newline character for all the last lines. For example: void TorqueGeneratedStruct<Struct, HeapObject>::StructPrint( std::ostream& os) { this->PrintHeader(os, "TorqueGeneratedStruct"); os << "\n"; } The last line could use a single character instead of a string, for example: void TorqueGeneratedStruct<Struct, HeapObject>::StructPrint( std::ostream& os) { this->PrintHeader(os, "TorqueGeneratedStruct"); os << '\n'; } The commit suggests changing this into a char. Change-Id: Id7a2f5fb17108fcbb543109d18b6b474ac1c5d2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108546Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66788}
-
Philip Pfaffe authored
This implements the first part of WebAssembly debug evaluate. The patch includes the foundation required to execute evaluator modules. It only implements the first of the APIs of the evaluator module spec. Bug: chromium:1020120 Change-Id: I06ec98a63d0a0ec8d81c2eac4319c4b85d3e16c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089936 Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66787}
-
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}
-
Emanuel Ziegler authored
Ported changes from the following CLs to mips/mips64: - https://chromium-review.googlesource.com/c/v8/v8/+/2066964 - https://chromium-review.googlesource.com/c/v8/v8/+/2071866 - https://chromium-review.googlesource.com/c/v8/v8/+/2080242 This change is needed for profiling of Wasm code that calls C-function to ignore the C-stack above the Wasm stack that otherwise couldn't be parsed otherwise. Bug: chromium:1045860 Change-Id: Ifdce5be6c5373714a67b3ce8d8c4f0a18f63b6fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082566Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#66785}
-
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}
-
Leszek Swirski authored
This reverts commit d91679bf. Reason for revert: Seems to cause UBSan errors 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=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66783}
-
Leszek Swirski authored
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}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/44de6a6..9b1394c Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/42d02fb..8413a03 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/a30b7bd..464e9ff TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ibfb16f9a6ca42a16fa40f6534d77bbe6e4ef5c39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109202Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66781}
-
- 18 Mar, 2020 3 commits
-
-
Milad Farazmand authored
"I64x2Eq", "S1x2AnyTrue" and "S1x2AllTrue" do not yet have lowering implemented hence some of the test case may fail on s390x hardware without AVX support. Change-Id: Ice01bcaed78950fbad36e2ba37c8f7ae5d10b59b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107763Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66780}
-
Ng Zhi An authored
This optimizes i8x16 shifts when the shift value is constant. It brings generated instruction counts down from 10 to 6 (unsigned), and 9 to 5 (signed). For Signed, we use a word (16-bit) shift, then mask away the high (shru) or low (shl) bits to achieve a byte shift. Most of the instructions are dedicated to building the mask. Bug: v8:10115 Change-Id: I1d5c0e0fb779eeb7e0185d3cb7fd595837fd8daf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106293Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66779}
-
Ng Zhi An authored
Bug: v8:10180 Change-Id: I700d10c82f6691bfc9a021fec120779c9d0a08e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107647Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66778}
-