- 22 Jun, 2021 1 commit
-
-
Dan Elphick authored
Moves VSNPrintf, SNPrintf and StrNCpy out of utils/utils.h into base/strings.h. Bug: v8:11879 Change-Id: I0e165cb27c42f89c9acd1c6378514b40a90cd18d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972732 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-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@{#75308}
-
- 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}
-
- 16 Mar, 2021 1 commit
-
-
Clemens Backes authored
This will make accidental includes much easier to see and fix. Without this, you might get compiler or linker errors instead. R=jkummerow@chromium.org Bug: v8:11238 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Change-Id: I235d779f9c1ed3af5d736f1554ded427935ddc9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2756531 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#73422}
-
- 14 Jan, 2021 1 commit
-
-
Manos Koukoutos authored
Changes: - Add --wasm-loop-unrolling flag. Everything in this CL happens behind this flag. - In decoding, DoReturn does not take returned values as an argument. It is now the responsibility of graph-builder-interface.cc to extract these values. Note that this is what was already happening in Liftoff. - In pipeline.cc, add phase to remove loop exits after generating the turbofan graph. - Explicitly disallow calling FallThruTo() on loops. - Add loop assignments and loop header node to Control type in graph-builder-interface.cc. Assign them in Loop(). - Main change: Add loop exit nodes to wasm-generated graphs. For details, consult this design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g - Inline PrepareForLoop(). Bug: v8:11298 Change-Id: I65058f1b5df3f862f4a62f4dcb0bd7e1f1dcf4ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621082 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72094}
-
- 09 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Clean up src/wasm and test/ Bug: v8:11074 Change-Id: I1b3d3475a0fbfafe75bb49acfd851f8bd5af5182 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519183Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71025}
-
- 15 Oct, 2020 2 commits
-
-
Ng Zhi An authored
read_prefixed_byte is used mostly to read an entire prefixed opcode, it writes the number of bytes of the opcode index (without prefix byte) to the out param length. Change it so it writes the total number of bytes (including the prefix byte), as that is what most callers want (they add 1 after calling read_prefixed_byte). Bug: v8:10810 Change-Id: I914190ecae62e3547652accdc05d1cef3686fff4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476678Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70551}
-
Ng Zhi An authored
Prefixed opcodes have a 1 byte prefix, followed by LEB-encoded u32. This changes all prefixed opcodes (gc, numeric, atomic), to that. (Simd was already so.) We can clean up read_prefix_opcode to return the total number of bytes, 1 byte prefix + leb encoded, that will be in a future patch. Bug: v8:10810,v8:10994 Change-Id: Ia74604acc059c1336b87e9f477598732de219ca9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465057Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#70544}
-
- 08 Oct, 2020 2 commits
-
-
Clemens Backes authored
It turns out that most LEBs are rather small (especially when used for locals). This CL adds a fast path for single-byte LEBs which is supposed to be inlined into callers. The more expensive slow path is then explicitly outlined to avoid excessive binary size growth. R=thibaudm@chromium.org Change-Id: I0dcdf597b9be3055acc2b878b6bee3fa21839758 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449974 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70408}
-
Clemens Backes authored
Remove one "mode" of LEB decoding by eliminating the {AdvancePCFlag}, and doing the PC advance in the caller instead. The returned length is now always zero in case of an error, thus remove the respective checks from the unit tests. The returned length does not really matter if we ran into an error. R=thibaudm@chromium.org Change-Id: Ibfd94dd981cefa2fc24c7af560c85afd1c826f2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449972Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70404}
-
- 07 Oct, 2020 1 commit
-
-
Clemens Backes authored
Methods defined within a class declaration are always inline by default, hence remove the redundant annotations. R=thibaudm@chromium.org Change-Id: I08e86996bad9596936220da849cdfaec5fffe1f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449970Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70368}
-
- 30 Sep, 2020 2 commits
-
-
Clemens Backes authored
All instantiations of the function body decoder (validation, Liftoff, TurboFan) currently generate precise error messages. For Liftoff though, the error message and location is never used. Thus we can save some binary size and performance by only keeping a flag whether an error occured or not. In the error case, the TurboFan compiler will execute right afterwards anyway, generating a proper error message. As as follow-up, we can avoid storing the pc in {ValueBase} and {ControlBase}, because that's only used for error reporting. R=thibaudm@chromium.org Bug: v8:10969 Change-Id: I65c46cb9d8b654f9476f2c34ca9a8dd45d6bbbc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436347 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70235}
-
Clemens Backes authored
As a preparation to add a "boolean validation" mode, rename the existing flags. This removes many unrelated changes from the follow-up change and makes it easier to review. R=thibaudm@chromium.org Bug: v8:10969 Change-Id: I5f71405b525a7caa91be46c035e31d4d960e4e4c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440036Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70224}
-
- 24 Sep, 2020 1 commit
-
-
Clemens Backes authored
This is a first small step for implementing the memory64 proposal: 1. Add a feature flag. 2. Add the 0x04 and 0x05 limits flag for memory64. 3. Read memory limits as LEB-encoded u64 (instead of u32) if a memory64 limit flag was read. 4. Unify {MaximumFlag} and {MemoryFlag}, which was used inconsistently before. 5. Add test for memory limits encoded with >5 bytes. 6. Move some macros from module-decoder-unittest.cc to wasm-macro-gen.h. Note that still the same limits for the maximum number of pages applies as before, i.e. you cannot specify a memory >4GB yet. But you can encode that small number in >5 bytes. R=manoskouk@chromium.org Bug: v8:10949 Change-Id: I90a4f08426ae714a67440281785eb00cfc24a349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423712 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#70110}
-
- 01 Jul, 2020 1 commit
-
-
Manos Koukoutos authored
Motivation: We used to approximate s33/i33 value parsing by first checking for specific negative codes, and then parsing an u32 value if that failed. This is not correct in all cases. Changes: - Implement i33 parsing in Decoder. - Factor out parsing of heap types into read_heap_type. - Introduce HeapType::kBottom. - Introduce helper functions in WasmFeatures and value_type_reader. - Remove macros from the parsing of value types. - HeapType::code now returns an i32 for compatibility with the i33 requirement. - Introduce HeapType::Repr. - Renamings: HeapType::type() -> representation(), ValueType::heap() -> heap_representation() Bug: v8:7748 Change-Id: I04deabce8837a48af2226411cd706a397f9e5725 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2274118 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68633}
-
- 24 Jun, 2020 2 commits
-
-
Clemens Backes authored
All error handling should be marked V8_UNLIKELY, because this is never on the hot path. R=thibaudm@chromium.org Bug: v8:10576 Change-Id: I8bc996e96a2e90f21ec065fbce4656d311097f74 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2263153Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68521}
-
Clemens Backes authored
This allows the compiler to eliminate more unneeded branches. Since all functions just do a lookup in a static table (either directly, or via compiling a switch to such a lookup), they are also good candidates for inlining, which is made possible by this change. One DCHECK is removed instead of pulling in the inl header, which would require more refactoring since the check is in a non-inl header. R=thibaudm@chromium.org TBR=jkummerow@chromium.org Bug: v8:10576 Change-Id: If0fd25fd62c5f30b896fc67a5458a5ae475a6351 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2259944 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#68508}
-
- 24 Apr, 2020 1 commit
-
-
Ng Zhi An authored
If module bytes end in a prefix like 0xfc (numeric prefix), we read out of bounds (pc + 1). So, if validate flag is set, check the length. Bug: chromium:1073553 Change-Id: Ia9771419d01f2315723d19dd96630172b5a7a1f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161404Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67370}
-
- 17 Apr, 2020 1 commit
-
-
Ng Zhi An authored
Bug: chromium:1071711 Bug: v8:10258 Change-Id: Id19add0c7e77ee3b834ff47274b9986cc2aa1f69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154767Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67216}
-
- 16 Apr, 2020 1 commit
-
-
Ng Zhi An authored
SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We were decoding this incorrectly as a fixed uint8. This fixes the decoder to properly handle multi bytes. In some cases, the multi byte logic is applied to all prefixed opcodes. This is not a problem, since for values < 0x80, the LEB encoding is a single byte, and decodes to the same int. If the prefix opcode has instructions with index >= 0x80, it would be required to be LEB128 encoded anyway. There are a bunch of trivial changes to test-run-wasm-simd, to change the macro from BUILD to BUILD_V, the former only works for single byte opcodes, the latter is a new template-based macro that correct handles multi-byte opcodes. The only unchanged test is the shuffle fuzzer test, which builds its own sequence of bytes without using the BUILD macro. Bug: v8:10258 Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#67186}
-
- 25 Feb, 2020 1 commit
-
-
Andreas Haas authored
This is a reland of 03d5a7ba Nothing changed here compared to the original test. The tests on the blink side were invalid, I fixed them in https://crrev.com/c/2066907. Original change's description: > [wasm] The name of a custom section can cause a validation error > > The WebAssembly spec defines that the name of a custom section can cause > a validation error. The streaming decoder, however, used a separate > Decoder object to decode the name, and thereby avoided a validation > error. With this CL the streaming decoder uses the main decoder to > decode the name of the custom section. > > In addition this CL removes the test mjsunit/regress/wasm/regress-789952. > This test defined an invalid WebAssembly module and expected it to > compile. As it is a regression test, it makes no sense to fix the test. > The module is invalid because it defines the length of the custom section > to be '0', so there are no bytes in the custom section for its name. > > R=clemensb@chromium.org > CC=thibaudm@chromium.org > > Bug: v8:10126 > Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66348} Bug: v8:10126 Change-Id: I48aaed8eb9899da1703030fb6809fe46a6e66191 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069325 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66431}
-
- 19 Feb, 2020 2 commits
-
-
Michael Achenbach authored
This reverts commit 03d5a7ba. Reason for revert: Needs rebaseline: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3243 Original change's description: > [wasm] The name of a custom section can cause a validation error > > The WebAssembly spec defines that the name of a custom section can cause > a validation error. The streaming decoder, however, used a separate > Decoder object to decode the name, and thereby avoided a validation > error. With this CL the streaming decoder uses the main decoder to > decode the name of the custom section. > > In addition this CL removes the test mjsunit/regress/wasm/regress-789952. > This test defined an invalid WebAssembly module and expected it to > compile. As it is a regression test, it makes no sense to fix the test. > The module is invalid because it defines the length of the custom section > to be '0', so there are no bytes in the custom section for its name. > > R=clemensb@chromium.org > CC=thibaudm@chromium.org > > Bug: v8:10126 > Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66348} TBR=ahaas@chromium.org,clemensb@chromium.org Change-Id: I5a7ea265ce47b9e685a5056bb83db6dc58f774a9 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10126 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065168Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66356}
-
Andreas Haas authored
The WebAssembly spec defines that the name of a custom section can cause a validation error. The streaming decoder, however, used a separate Decoder object to decode the name, and thereby avoided a validation error. With this CL the streaming decoder uses the main decoder to decode the name of the custom section. In addition this CL removes the test mjsunit/regress/wasm/regress-789952. This test defined an invalid WebAssembly module and expected it to compile. As it is a regression test, it makes no sense to fix the test. The module is invalid because it defines the length of the custom section to be '0', so there are no bytes in the custom section for its name. R=clemensb@chromium.org CC=thibaudm@chromium.org Bug: v8:10126 Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66348}
-
- 30 Oct, 2019 1 commit
-
-
Clemens Backes authored
The same functionality can be achieved by just setting a breakpoint in that function. R=ahaas@chromium.org Bug: v8:9810 Change-Id: Ieb5e99b5c2f0b492e32e75cae0c0b9292accd932 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888072Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64646}
-
- 16 Oct, 2019 1 commit
-
-
Clemens Backes authored
The lookahead did not check whether there is actually a byte left to be read. So if the i32 comparison was the last byte in the function body, we would read out of memory. This CL fixes that by introducing a separate {lookahead} method which does the proper bounds check and the lookahead. R=jkummerow@chromium.org Bug: chromium:1014834, v8:9831 Change-Id: I6499ae3f2c57d38a8fcb587b99ae4a4a6c70e426 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864939Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64335}
-
- 21 Jun, 2019 1 commit
-
-
Sigurd Schneider authored
v8memory.h does not have V8 specific definitions, and having it in base makes it clear that every component may include the file. It also ensures that including it does not create spurious dependencies on v8_base. Change-Id: I565f63b25f33a9ada19d7b2ac5990863ab17f4a7 Bug: v8:9183, v8:8855 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657923 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62309}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 15 May, 2019 1 commit
-
-
Clemens Hammacher authored
All macros defined in "format-macros.h" are dead now (after https://crrev.com/c/1613243). This CL removes this header, and includes <cinttypes> instead wherever we use format macros for the types defined in <cstdint>. Plus some drive-by cleanup of includes. R=mlippautz@chromium.org Bug: v8:9183 Change-Id: Ic379759b79edb50e38833defb1577cc3af7c8150 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611800 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#61540}
-
- 29 Apr, 2019 1 commit
-
-
Clemens Hammacher authored
Our {Vector} template provides both {start} and {begin} methods. They return exactly the same value. Since the {begin} method is needed for iteration, and is also what standard containers provide, this CL switches all uses of the {start} method to use {begin} instead. Patchset 1 was auto-generated by using this clang AST matcher: callExpr( callee( cxxMethodDecl( hasName("start"), ofClass(hasName("v8::internal::Vector"))) ), argumentCountIs(0)) Patchset 2 was created by running clang-format. Patchset 3 then removes the now unused {Vector::start} method. R=jkummerow@chromium.org TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org Bug: v8:9183 Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61081}
-
- 29 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
Even though both are allowed in the style guide, it recommends to use 'using', as its syntax is more consistent with the rest of C++. This CL turns all typedefs in wasm code to 'using' declarations. R=ahaas@chromium.org Bug: v8:8834 Change-Id: Ibdce88a5cc31e0785cbc1b34088bd39aa3ec84b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545890Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60519}
-
- 14 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
This simplifies some code by removing unneeded checks and early returns. I just accidentally hit got one more instance of this, and I think we should get rid of the requirement of only decoding LEBs that start before the end pointer of the decoder. R=titzer@chromium.org Change-Id: I608c5c1c292088ac14fac20b7cb030f39c165bd7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523550Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60238}
-
- 26 Feb, 2019 2 commits
-
-
Sigurd Schneider authored
Change-Id: I4bd02bdb68727b6242b0fe4b81fd522813b13f39 Bug: v8:8834 Reviewed-on: https://chromium-review.googlesource.com/c/1488755Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59875}
-
Sigurd Schneider authored
Remove EmbeddedVector from utils.h Bug: v8:8834, v8:8912 Change-Id: I04e9f12121757bd0b87c68d7a4a5b213c2d8b686 Reviewed-on: https://chromium-review.googlesource.com/c/1486473Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59854}
-
- 28 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The workaround is simple: cast to unsigned before shifting. Bug: v8:3770 Change-Id: I5f0f7af697ec5db0ab1df3d061008940c83c5c56 Reviewed-on: https://chromium-review.googlesource.com/c/1436215Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#59140}
-
- 15 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
We often use ResultBase or VoidResult to store or pass wasm errors (errors with locations). This CL extracts a WasmError class which can store an error (can also be empty), and Result<T> which stores an error or a T (exactly one of them). R=titzer@chromium.org Bug: v8:8689 Change-Id: I3f5203559984a0ae8757e0130a9184957fa28df5 Reviewed-on: https://chromium-review.googlesource.com/c/1409365 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#58827}
-
- 30 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
This has significant impact on validation time (11% regression, see linked bug). These annotations bring us back to the old performance (according to local measurements it even makes us better than before). R=mstarzinger@chromium.org Bug: chromium:910432 Change-Id: I8e701f9577d53115b3db22be2a09487414c965df Reviewed-on: https://chromium-review.googlesource.com/c/1356511Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57973}
-
- 29 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
This adds error functions that receive offsets instead of pc, since the streaming compiler stores different sections in different buffers, so computing pointer differences between different sections does not work. We keep the pc-based methods for now to reduce code-churn and complexity at the different call sites. R=ahaas@chromium.org CC=binji@chromium.org Bug: v8:8238 Change-Id: I1aa68740bdda93c3341431aa7a81ac01ecfb71bb Reviewed-on: https://chromium-review.googlesource.com/c/1354463Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57944}
-
- 22 Oct, 2018 1 commit
-
-
Clemens Hammacher authored
This removes the {error} and {verror} methods of {ResultBase} and introduces a named constructor {Error} instead. This allows to construct an error result in a single expression, and moves {Result} closer to a container that is initialized once and is immutable afterwards (just the {MoveErrorFrom} method is still violating this pattern). R=titzer@chromium.org Bug: v8:8238 Change-Id: Iec16c8c6d66300ee82a48e8a9e941c72ae26e202 Reviewed-on: https://chromium-review.googlesource.com/c/1293370 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56857}
-
- 19 Oct, 2018 1 commit
-
-
Clemens Hammacher authored
And remove the TurboFan/Liftoff specific {FinishCompilation} implementations completely. Compilation errors are now stored in the {WasmCompilationUnit} directly as a {Result<WasmCode*>}. They are retrieved via {WasmCompilationUnit::ReportError}, which moves the error to the {ErrorThrower}. This prepares more changes to completely remove the {FinishCompilation} phase. R=titzer@chromium.org Bug: v8:7921 Change-Id: I4f9a6e919359aeab074880d0d38211500b76e4ec Reviewed-on: https://chromium-review.googlesource.com/c/1290975 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56826}
-