- 24 Oct, 2019 1 commit
-
-
Clemens Backes authored
This will allow us to reuse this method in other contexts. This CL also contains smaller refactorings that helped to move the code. E.g. the WASMVALUE_CTYPES macro (defined in value-type.h) replaces the WASM_CTYPES macro (from wasm-interpreter.cc). R=mstarzinger@chromium.org Bug: v8:9676 Change-Id: Id788f843af9a09eb940593afa1639f12b652c514 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876054 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64534}
-
- 23 Oct, 2019 3 commits
-
-
Deepti Gandluri authored
Bug: chromium:1010272 Change-Id: Ieff61089255ee088fad45f15a0f1a8f93eeec94b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869077 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64525}
-
Clemens Backes authored
These accessors do not make any use of the interpreter, hence we can define them on the WasmInstanceObject alone. This will allow to reuse them for other (non-interpreted) frames. R=mstarzinger@chromium.org Bug: v8:9676 Change-Id: Iff8b665a4c25581b934c25b66a13cebe044cb02c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1875097Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64511}
-
Clemens Backes authored
R=mstarzinger@chromium.org Bug: v8:9810 Change-Id: Ib08647b5d6c4238732eed5a2ed1f1d0eea010076 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1875099Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64504}
-
- 22 Oct, 2019 4 commits
-
-
Thibaud Michaud authored
R=mstarzinger@chromium.org Bug: v8:6672 Change-Id: Id8a53f6f74fa05150469c35ceba9470e75363637 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847156Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#64472}
-
Thibaud Michaud authored
Block inputs are removed from the stack. Set expected stack height accordingly. R=ahaas@chromium.org Bug: v8:9867 Change-Id: I7e3fd2985c0e77e83d5551cac613788f3cf0a370 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872404 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64465}
-
Clemens Backes authored
If a new jump table is created and lazy compilation is enabled, we need to initialize the new jump table with jumps to the lazy compile table. R=ahaas@chromium.org Bug: chromium:1016515 Change-Id: I5749470d4a08af903a6a4da13dbe5454ee6db309 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873687Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64462}
-
Jakob Gruber authored
This CL removes the V8_EMBEDDED_BUILTINS define, FLAG_embedded_builtins, and all code for supporting non-embedded-builtin builds. Bug: v8:6666,v8:8519 Change-Id: I2ad7bd6614c7cd404b83d3d2bf5ff91d7b55ff2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866569 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64461}
-
- 21 Oct, 2019 2 commits
-
-
Clemens Backes authored
The MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR macro defines a defaulted move constructor and move-assignment operator. The {std::unique_ptr} on the other hand needs the contained type to be complete when instantiating the move assignment operator. Hence, this fails e.g. on MSVC, see https://github.com/nodejs/node/pull/30020#issuecomment-544485991. It turns out that we never actually move the interpreter, so we can just replace the MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR by DISALLOW_COPY_AND_ASSIGN. R=ahaas@chromium.org Change-Id: Iba7d30243510ed9554be62b0c4c8e6f47f0c3307 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871921Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64423}
-
Mu Tao authored
Port 7d09b270 Original Commit Message: It turns out that because we are *subtracting* from fp, we need to *subtract less* to get a higher address. Who knew. R=xwafish@gmail.com, clemensb@chromium.org Change-Id: I1ddb5e15ef7fab2f198aebf07a5ce607add4c3c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868559 Auto-Submit: Mu Tao <pamilty@gmail.com> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64406}
-
- 17 Oct, 2019 2 commits
-
-
Ng Zhi An authored
This is a reland of 306bb635 Original change's description: > [wasm-simd] Implement F64x2ConvertI64x2 for x64 > > Bug: v8:8460 > Change-Id: Icefb90c67af77ac93bd75b4e452ba426232de83a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710332 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Bill Budge <bbudge@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63627} Bug: v8:8460 Change-Id: I08d2c88e81ce51d3d1cfdf3d7d6ba34792e34e9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1793902Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64365}
-
Milad Farazmand authored
Port 7d09b270 Original Commit Message: It turns out that because we are *subtracting* from fp, we need to *subtract less* to get a higher address. Who knew. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ide47f62b5fbfd309a2892fcd934175db7e390a8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864586Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64340}
-
- 16 Oct, 2019 12 commits
-
-
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}
-
Thibaud Michaud authored
R=clemensb@chromium.org Change-Id: I061ca50c08cfa2bc60e74e4387e3e2933659202b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864655Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#64333}
-
Clemens Backes authored
Instead of spilling x0 and x1 to the stack, use temp registers which should always be available in this situation. This avoids the spill and load. Also, switch from holding {start} and {end} in the register to holding {start} and {count}. This make it easier to correctly initialize the registers. R=joey.gouly@arm.com Bug: v8:9830 Change-Id: I5fc8b8603afaf12fad2ba66cd7a75555ef31bd4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859618 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64332}
-
Clemens Backes authored
Most comparisons are followed by a br_if instruction. This CL detects that for i32 comparisons and folds them with a following br_if, avoiding to materialize the result of the comparison as 0 or 1 in a register. This saves three out of the five instructions generated for this pattern before. Plus some drive-by cleanup. R=jkummerow@chromium.org Bug: v8:9831 Change-Id: I7bed47f2523b60b2bf301f074fe3132aea9a0636 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862561 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64330}
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: I2eb419bbfbea81d58b1c13e527af1728d84c4092 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864656Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64329}
-
Michael Starzinger authored
This extends existing table support to be able to store 'exnref' in addition to 'anyref' types. Tools can use this to maintain data structures for exception packages. R=ahaas@chromium.org TEST=mjsunit/wasm/exceptions-anyref BUG=v8:8091 Change-Id: Iccbcfdc328db81a366921bcdd98c2256f66e7fc8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781046 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64323}
-
Michael Starzinger authored
With the recent removal of the --wasm-shared-code flag, it became effectively impossible to turn off this flag. Hence its functionality became mandatory and the ability to turn off sharing of {WasmEngine} process-wide has to be removed as well. R=clemensb@chromium.org Change-Id: I7c25e909e49134a226d6a9fe9c42f0ecd9d02a69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864935 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64322}
-
Clemens Backes authored
It turns out that because we are *subtracting* from fp, we need to *subtract less* to get a higher address. Who knew. R=jkummerow@chromium.org Bug: v8:9830, chromium:1014798 Change-Id: I5b9782dd0be27f4c3efbd306ec6c3450b249cb55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864933Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64321}
-
Mu Tao authored
Port a8cdda99 Original Commit Message: WebAssembly locals are specified to be zero on function entry. Liftoff implements this by just storing the constant 0 in the virtual stack for integer types, and using one floating point register initialized to zero for all floating point types. For big counts of locals this leads to problems (manifesting as huge blocks of code being generated) once we hit a merge point: All those constants (for int) and all duplicate register uses (for floats) need to be fixed up, by using separate registers for the locals or spilling to the stack if no more registers are available. All this spilling generates a lot of code, and can even happen multiple times within a function. This CL optimizes for such cases by spilling all locals to the stack initially. All merges within the function body get much smaller then. The spilled values rarely have to be loaded anyway, because the initial zero value is usually overwritten before the first use. To optimize the code size for initializing big numbers of locals on the stack, this CL also introduces the platform-specific {FillStackSlotsWithZero} method which uses a loop for bigger local counts. This often saves dozens of kilobytes for very big functions, and shows an overall code size reduction of 4-5 percent for big modules. R=xwafish@gmail.com Change-Id: Id65b6d36beadcba0d3f3726bb6559bb316cb212e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862830 Auto-Submit: Mu Tao <pamilty@gmail.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Mu Tao <pamilty@gmail.com> Cr-Commit-Position: refs/heads/master@{#64315}
-
Thibaud Michaud authored
This prevents the branch table iterator's has_next() method to trigger a DCHECK when the decoder fails before the end of table decoding. R=clemensb@chromium.org Change-Id: I2258886501b77cd4c8fe98bc8a4ed0b66fb23066 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864931Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#64312}
-
Thibaud Michaud authored
R=ahaas@chromium.org Change-Id: I0405abbd8fc047653758ac41d185bf0f44e33d09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859617 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64309}
-
Michael Starzinger authored
R=clemensb@chromium.org BUG=v8:6847,chromium:893069 Change-Id: I5b5ada546e1d0b9d42ea8f7278671bf2b128bef8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862570Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64308}
-
- 15 Oct, 2019 5 commits
-
-
Milad Farazmand authored
Port a8cdda99 Original Commit Message: WebAssembly locals are specified to be zero on function entry. Liftoff implements this by just storing the constant 0 in the virtual stack for integer types, and using one floating point register initialized to zero for all floating point types. For big counts of locals this leads to problems (manifesting as huge blocks of code being generated) once we hit a merge point: All those constants (for int) and all duplicate register uses (for floats) need to be fixed up, by using separate registers for the locals or spilling to the stack if no more registers are available. All this spilling generates a lot of code, and can even happen multiple times within a function. This CL optimizes for such cases by spilling all locals to the stack initially. All merges within the function body get much smaller then. The spilled values rarely have to be loaded anyway, because the initial zero value is usually overwritten before the first use. To optimize the code size for initializing big numbers of locals on the stack, this CL also introduces the platform-specific {FillStackSlotsWithZero} method which uses a loop for bigger local counts. This often saves dozens of kilobytes for very big functions, and shows an overall code size reduction of 4-5 percent for big modules. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2459080a1f6acfdd212e9a93a868d028980c5554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863370Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64301}
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: I9dab61c4260436d08171ac0ff084e05d75c5c5e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862573Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64298}
-
Clemens Backes authored
We currently generate code for both separately, resulting in five instructions (three for the i32_eqz, two for the br_if): test rax,rax seteq dl movzxb rdx,rdx test rdx,rdx jz <label> After this CL, we just generate two instructions: test rax, rax jnz <label> This is implemented by a look-ahead in the {kExprI32Eqz} handler. If the opcode is followed by {kExprBrIf}, no code is emitted. Instead, a flag in the {LiftoffCompiler} is set to signal to the {kExprBrIf} handler that the previous instruction was not processed yet. Note that this mechanism is designed to be reusable for more similar improvements. For the single instance implemented in this CL, it is not needed. Plus some drive-by cleanup. R=jkummerow@chromium.org Bug: v8:9831 Change-Id: I47495fe763b7db7cef41aa207c88a2f1b74bf1a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862557 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64292}
-
Michael Starzinger authored
This replaces all left-over uses of {WasmGraphBuilder::Buffer} with proper alternatives (e.g. using {base::SmallVector} instead). R=clemensb@chromium.org Change-Id: I2607ce7e2638a1bb35daccbb5b38382d5b62a430 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859626Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64285}
-
Clemens Backes authored
WebAssembly locals are specified to be zero on function entry. Liftoff implements this by just storing the constant 0 in the virtual stack for integer types, and using one floating point register initialized to zero for all floating point types. For big counts of locals this leads to problems (manifesting as huge blocks of code being generated) once we hit a merge point: All those constants (for int) and all duplicate register uses (for floats) need to be fixed up, by using separate registers for the locals or spilling to the stack if no more registers are available. All this spilling generates a lot of code, and can even happen multiple times within a function. This CL optimizes for such cases by spilling all locals to the stack initially. All merges within the function body get much smaller then. The spilled values rarely have to be loaded anyway, because the initial zero value is usually overwritten before the first use. To optimize the code size for initializing big numbers of locals on the stack, this CL also introduces the platform-specific {FillStackSlotsWithZero} method which uses a loop for bigger local counts. This often saves dozens of kilobytes for very big functions, and shows an overall code size reduction of 4-5 percent for big modules. R=jkummerow@chromium.org Bug: v8:9830 Change-Id: I23fa4145847827420f09e043a11e0e7b606e94cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856004 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64282}
-
- 14 Oct, 2019 4 commits
-
-
Michael Starzinger authored
This switches the {WasmGraphBuilder} to use {SmallVector} for passing argument and return values. It deprecates {WasmGraphBuilder::Buffer}, which is a dangerous construct as it makes it easy to accidentally use the single buffer for two vectors at the same time. This also removes the by now unused {WasmGraphBuilder::Realloc} method. R=clemensb@chromium.org Change-Id: I6bd9be437a99c23bb403a046a75c148ac4a14451 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859619Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64277}
-
Michael Starzinger authored
This switches the {WasmGraphBuilder::GetExceptionValues} to use a proper vector instead of the deprecated {Buffer} method. This also addresses a TODO about missing landing pads for the above affected method. R=clemensb@chromium.org Change-Id: I33ba7d712a00f2a284ec159a501bcd90e02a3a51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859620 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64276}
-
Thibaud Michaud authored
R=ahaas@chromium.org Change-Id: Iea0fe775eb8c101200fe41e5e188bbdc85c03df7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856000Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#64272}
-
Michael Starzinger authored
With exception handling enabled new call paths open up, which will perform environment merging while a "call" or "call_indirect" is currently being emitted. This will lead to double-use of the buffer returned by calls to {Buffer} or {Realloc}. In general we should transition away from this optimization to safer constructs such as {base::SmallVector} to avoid such bugs. R=clemensb@chromium.org TEST=mjsunit/regress/regress-9832 BUG=v8:9832 Change-Id: I4c862ac1bc7dc34ad62279c82f6414153e8cbddb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856006 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64271}
-
- 11 Oct, 2019 2 commits
-
-
Ng Zhi An authored
Increase the embedded vector size to 91 as that is the max size needed to print a s128 as a 32x4. - max value of uint32_t has 10 digits in decimal, 1 for a potential sign, 3 spaces in between 4 of them -> 3 + 4 * 11 = 47 - max value of uint32_t has 8 digits in hex, 3 spaces in between -> 3 + 4 * 8 = 35 - the prefix "v128:" -> 5 - " / " to separate the decimal and hex representation -> 3 - null byte 47 + 35 + 5 + 3 + 1 = 91 Bug: v8:9754 Change-Id: I153c30738fa8862b44fb5103cbe62ea0bcea9718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814885 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64256}
-
Ulan Degenbaev authored
The backing store is now propagated to the constructors directly, instead of being attached after the construction. This ensures that the backing store is allocated before the array buffer so that we can trigger GCs on backing store allocation (if allocation fails). The only exception is builtin where we have to allocate the array buffer before the backing store to comply with the spec. Bug: v8:9380 Tbr: verwaest@chromium.org Change-Id: Ib37db65853f3673dd769368cc3e8b6538ad07ff2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1853444 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64240}
-
- 10 Oct, 2019 2 commits
-
-
Michael Starzinger authored
This moves the list of {BreakPointInfo} objects from {WasmModuleObject} to the corresponding {Script} object. Breakpoints are expected to affect all modules/instances for a given script, hence the new placement of the list is a preparation to fully support per-script breakpoints. R=clemensb@chromium.org BUG=v8:6847,chromium:893069 Change-Id: Id97058be5ed79cfdba2cecac5733ba161a6021d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852127Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64213}
-
Clemens Backes authored
The flag is enabled since M-70, and we do not use the previous behaviour anywhere. Hence, remove the flag and clean up some API code. In particular, the concept of {TransferrableModule} is not needed any more, we can just use {CompiledWasmModule}. R=mstarzinger@chromium.org, adamk@chromium.org Bug: v8:9810 Change-Id: I9b3aa4972277a9262b58da70b141e90d1de31f35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847366 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64209}
-
- 09 Oct, 2019 3 commits
-
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I79ae753f15aaa91a2154bd7078a1cdb9f3e049f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822497Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64201}
-
Seth Brenith authored
In preparation for allowing Torque to generate the list of instance types, I'd like to make the rules a bit more consistent for how instance types are spelled. This CL is my proposal for a system where every non-String instance type name is exactly equal to calling CapifyStringWithUnderscores on the corresponding class name and appending "_TYPE". This change is almost all find&replace; the only manual changes are in: - src/objects/instance-type.h - src/torque/utils.cc - tools/gen-postmortem-metadata.py This change is in response to the review comment https://chromium-review.googlesource.com/c/v8/v8/+/1757094/25/src/builtins/base.tq#132 Change-Id: Ife3857292669f54931708e934398b2684e60bea5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814888 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#64199}
-
Michael Starzinger authored
This moves the weak list of instances from {WasmModuleObject} to the corresponding {Script} object. The list is used solely for breakpoints which are intended to affect all instances belonging to a given script, hence the new placement of the list is a preparation to fully support per-script breakpoints. R=clemensb@chromium.org BUG=v8:6847,chromium:893069 Change-Id: I52315e0ba1e5e5021f55bf05d8cb0f01bf9f0fbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847359 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64191}
-