- 31 Jan, 2019 15 commits
-
-
Takuto Ikuta authored
I extracted following class member functions to string.cc * String * SeqString * SeqOneByteString * SeqTwoByteString * ConsString * ThinString * SlicedString * ExternalString * FlatStringReader * ConsStringIterator Declaration of all above class are in string.h. This patch makes compile time of objects.cc from 20.6s to 19.2s on Z840 Linux. Bug: v8:7629 Change-Id: If74b868b3a3d9a1df2887f82e2557da43ad221f0 Reviewed-on: https://chromium-review.googlesource.com/c/1446342Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Takuto Ikuta <tikuta@chromium.org> Cr-Commit-Position: refs/heads/master@{#59235}
-
Pierre Langlois authored
The arm64 backend defines registers with a common base `CPURegister` class which can represent both general purpose and vector registers. We would use it to define the `RegisterName` function which results in printing all registers with `xN` when using the --trace-turbo-graph flag: ~~~ [x0|R|f64] = Arm64LdrD : MRR [x7|R|tp] [x5|R|w64] ^^ This is the d0 register, not x0 ~~~ We have `Register` and `VRegister` classes to distinguish general purpose registers from vector registers, use those to define `RegisterName` functions and print vector registers as `vN` intead: ~~~ [v0|R|f64] = Arm64LdrD : MRR [x7|R|tp] [x5|R|w64] ~~~ Since FloatRegister, DoubleRegister and Simd128Register are typedef of VRegister, we cannot differentiate them with the current `DEFINE_REGISTER_NAMES` abstraction. Architecturaly, S, D and Q registers are aliases of V registers so that's not a problem. Change-Id: Ic43036117c834070d3311b65c99ad1e24e1f9c3f Reviewed-on: https://chromium-review.googlesource.com/c/1445990Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#59234}
-
Tamer Tas authored
R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org No-Try: True Bug: v8:8174 Change-Id: Ia77a42f3dce741f661f3d7aee3af2237e53ae0f0 Reviewed-on: https://chromium-review.googlesource.com/c/1447713Reviewed-by:
Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#59233}
-
Georg Neis authored
This reverts commit 595aafeb. Reason for revert: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8922824501209195616/+/steps/Mozilla/0/logs/15.8.2.13/0 Original change's description: > [builtins] [turbofan] Refactor Float64Pow to use single implementation > > Remove platform-specific Float64Pow implementations and utils Pow in > favor of a base::ieee754::pow implementation. > > This unifies the implementation of pow for the compiler, wasm, and > runtime. > > Bug: v8:5848, v8:5086 > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23 > Reviewed-on: https://chromium-review.googlesource.com/c/1403018 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59229} TBR=yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,clemensh@chromium.org,me@gus.host Change-Id: I266df4b8350cfcebcea8f6063ad75ad962381105 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5848, v8:5086 Reviewed-on: https://chromium-review.googlesource.com/c/1447715Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59232}
-
Tamer Tas authored
R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org No-Try: true Bug: v8:8174,v8:8728,v8:8763 Change-Id: I27faa43e775b4a834a7c2af3ec1407afb71bb06e Reviewed-on: https://chromium-review.googlesource.com/c/1447714 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Georg Neis authored
Also use the feedback as a hint for the target, because target and new.target are often the same and we have no way of checking that in the serializer. Bug: v8:7790 Change-Id: I9647bf9ab830a76657de400f413fc1cb798a2ade Reviewed-on: https://chromium-review.googlesource.com/c/1445988Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59230}
-
Clemens Hammacher authored
Remove platform-specific Float64Pow implementations and utils Pow in favor of a base::ieee754::pow implementation. This unifies the implementation of pow for the compiler, wasm, and runtime. Bug: v8:5848, v8:5086 Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23 Reviewed-on: https://chromium-review.googlesource.com/c/1403018 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59229}
-
Michael Starzinger authored
This adds support for handling exceptions between different frames of one single interpreter activation. Frames are dropped until a local handler is found. If none is found in the current activation then we delegate to the existing stack unwinding mechanism to deal with multiple activations interspersed with non-interpreter stack frames on the actual machine stack. R=clemensh@chromium.org TEST=cctest/test-run-wasm-exceptions BUG=v8:8091 Change-Id: Ia4abb27ff037bf0d3e3b05721bd3c971ef820e3c Reviewed-on: https://chromium-review.googlesource.com/c/1445989 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
Change-Id: Iec5d7b2c73b45012d3bc457f0928c7f39afc8815 Reviewed-on: https://chromium-review.googlesource.com/c/1446454 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#59227}
-
Jaroslav Sevcik authored
In particular, test all integrity level transitions properly. The motivation for this fix was to get rid of the test that introduce {frozen_symbol} transition while leaving properties configurable and writable. This CL tests each integrity transition separately, and sets the attributes accordingly. Bug: v8:8538 Change-Id: I741d87bba1472aec68bf92084e65edc16c1e08d8 Reviewed-on: https://chromium-review.googlesource.com/c/1446097Reviewed-by:Igor Sheludko <ishell@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#59226}
-
Clemens Hammacher authored
The CompilationState should not be bound to a specific isolate. Hence it cannot start foreground task. Instead, the callbacks themselves should do this if they are specific to one Isolate. R=mstarzinger@chromium.org Bug: v8:8689, v8:8050 Change-Id: Ic86bba1dd645401b2b284a9f26eec87718b011e1 Reviewed-on: https://chromium-review.googlesource.com/c/1445977 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59225}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/5d6f467..f27d150 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/2f02e1f..6fbda1b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1a9772f..bc2b64b Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/b695155..1131ccb Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/361dfd1..3a06ff3 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I8be0096df86593d061f48d3d2609c1a9a9a6dc19 Reviewed-on: https://chromium-review.googlesource.com/c/1446150Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#59224}
-
Tamer Tas authored
loading every test up-front into the processing queue costs about 224MB for a x64 testsuite run. This CL eliminates that overhead by utilizing generators and threading. LoadingProc now loads test after receiving the results of the loaded tests. R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org Bug: v8:8174,v8:8731 Change-Id: Ifee79c3e213da568f092de0f1623016174e9410c Reviewed-on: https://chromium-review.googlesource.com/c/1439240 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
The build config inherited from Chromium only enables a subset of the checks that UBSan supports. We want them all, so this patch overrides what "is_ubsan" means for V8. Bug: v8:3770 Change-Id: I1d0a7d994279272f13ff1d4ac9ed235fcbfc0951 Reviewed-on: https://chromium-review.googlesource.com/c/1443502 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Sergiy Belozorov authored
This is a reland of d045f666 Original change's description: > [tools] Push files using high-level device.PushChangedFiles method > > R=machenbach@chromium.org > > No-Try: true > Bug: chromium:893593 > Change-Id: I11cce7694eb7755ccee42c9a342fc1aa22663d85 > Reviewed-on: https://chromium-review.googlesource.com/c/1382468 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58407} Bug: chromium:893593 Change-Id: I88a7143b3f31d87d266b89221f81efe831ea3823 Reviewed-on: https://chromium-review.googlesource.com/c/1443055 Commit-Queue: Andrii Shyshkalov <tandrii@chromium.org> Reviewed-by:
-
- 30 Jan, 2019 25 commits
-
-
Sven Sauleau authored
We noticed that almost every call site were loading both files, the split isn't necessary anymore. In some message tests, removed the absolute line number to allow future changes. Bug: v8:8726 Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545 Reviewed-on: https://chromium-review.googlesource.com/c/1446452 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59220}
-
Jakob Gruber authored
Now that we generate the embedded blob and off-heap trampolines directly after builtin generation, the heap should not contain any remaining references to full on-heap builtin Code objects. The one exception is the interpreter entry trampoline copy for profiling. This mechanism was actually broken by canonicalization; we intended to store a full copy of the IET on the root list, but serialization replaced it with the canonicalized builtin. This CL fixes that as a side-effect. Bug: v8:8716 Change-Id: Ib37c4004560d67de46b1f8ebe75156361134f57d Reviewed-on: https://chromium-review.googlesource.com/c/1421037 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Junliang Yan authored
Port ad3546ab Original Commit Message: This is an initial step towards clarifying the layout of the instruction area. As follow-ups, we should remove additional safepoint and handler table offset parameters, and perhaps alter Code::safepoint_table_offset (handler_table) semantics to always contain a real offset and avoid the magic 0 signifying nonexistent tables. R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I6c2d3244710f8f3f33bcceb3988e19547f55fba0 Reviewed-on: https://chromium-review.googlesource.com/c/1446138Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59218}
-
Igor Sheludko authored
addp, andp, cmpp, decp, incp, leap, negp, orp, subp, testp, xorp, shrp, sarp, shlp are replaced with respective quad-word instructions. Some wrongly-used xxxp instructions in regexp code are replaced with xxxl. Bug: v8:8621, v8:8562 Change-Id: If5fe3229a35805b8ef84d3e1ffa05cf9ed91ceef Reviewed-on: https://chromium-review.googlesource.com/c/1446451Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#59217}
-
Clemens Hammacher authored
Instead of passing the error explicitly, make the callbacks get the error from the CompilationState. This prepares a change to call the callbacks asynchronously, because from the background we cannot construct the final error message (because this requires access to the wire bytes). Thus the callbacks will have to get the actual compile error from the CompilationState from a foreground task if they need it. R=mstarzinger@chromium.org Bug: v8:8689 Change-Id: I22accabf895bf21fa7492e2f5cb8bac93237c765 Reviewed-on: https://chromium-review.googlesource.com/c/1445975 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Takuto Ikuta authored
By using different namespace, generated code split into different files. By this CL, build time of torque_generated_initializers is improved from 80 seconds to 40 seconds on Z840 Linux measured by following command: # Remove generated code to re-compile all generated files. ~/v8/v8$ rm -rf out/x64.release/gen/ # GOMA_STORE_ONLY=true disables goma's backend cache. ~/v8/v8$ time GOMA_STORE_ONLY=true autoninja -C out/x64.release/ torque_generated_initializers Bug: v8:8732 Change-Id: I64545f9994aea7e4209ac3852aadf4e2e9f4bc93 Reviewed-on: https://chromium-review.googlesource.com/c/1446331Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Takuto Ikuta <tikuta@chromium.org> Cr-Commit-Position: refs/heads/master@{#59215}
-
Benedikt Meurer authored
For instances created via constructors and `new` we try to pre-size the instances such that ideally all the data properties can be allocated as in-object properties (and we don't need to allocate the out-of-object PropertyArray backing store). This is accomplished with the helper of the Parser, which counts the property assignments to `this` in the constructor, and we use that as the starting point for pre-sizing logic (a mechanism called *slack tracking* is used to dynamically shrink the objects based on the real memory usage, and eventually compute the final starting size for instances of the individual constructors). This works well even with class hierarchies, since for a derived class constructor we just include the current constructor plus all the base constructors. I.e. with ```js class A { constructor() { this.x00 = null; this.x01 = null; this.x02 = null; this.x03 = null; this.x04 = null; this.x05 = null; this.x06 = null; this.x07 = null; this.x08 = null; this.x09 = null; this.x10 = null; this.x11 = null; this.x12 = null; this.x13 = null; this.x14 = null; this.x15 = null; this.x16 = null; this.x17 = null; this.x18 = null; this.x19 = null; } } class B extends A { constructor() { super(); } } ``` we will eventually learn that instances of `B` need 20 in-object properties. However this breaks with transpiled code (i.e. as generated via TypeScript or Babel), even when the constructors are properly chained. ```js function A() { this.x00 = null; this.x01 = null; this.x02 = null; this.x03 = null; this.x04 = null; this.x05 = null; this.x06 = null; this.x07 = null; this.x08 = null; this.x09 = null; this.x10 = null; this.x11 = null; this.x12 = null; this.x13 = null; this.x14 = null; this.x15 = null; this.x16 = null; this.x17 = null; this.x18 = null; this.x19 = null; } function B() { A.call(this); } Object.setPrototypeOf(B, A); ``` Here we will always have 10 in-object properties for instances of `B` (due to the generic over-allocation logic), and the other 10 properties have to be allocated in the out-of-object PropertyArray. This is unfortunate and actually not necessary. Instead we could just do the same [[Prototype]] walk on the constructor for regular function constructors that we perform for derived (native) class constructors. This CL changes that, such that we give the same treatment to transpiled class that we have for native classes. R=verwaest@chromium.org Bug: v8:8764, v8:8765 Doc: https://bit.ly/v8-instance-presizing-with-transpiled-classes Change-Id: Iac54391e41c9a39101751a678b3a647269fb009d Reviewed-on: https://chromium-review.googlesource.com/c/1442643 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59214}
-
Sven Sauleau authored
Changes made to the Wasm module builder: - Create emit_u64v for emitting a LEB128 that conceptually represent an 64-bits integer. - Differentiate toBuffer and toUint8Array for returning respectively ArrayBuffer and a Uint8Array. - Moved wasmF32Const and wasmF64Const functions because we can take advantage of the existing cached conversion buffers. Also, declaring them in the constants file will collide with the module-builder since they are loaded in the same scope. - The byte_view buffer (used by some conversions to bytes) switched from Int8Array to Uint8Array. Changes made to the Wasm contants: - Add a new kSharedHasMaximumFlag flag for shared memory with a maximum value. Bug: v8:8726 Change-Id: If16c59896cfa1d42008da413e2e144b73a0fa5ce Reviewed-on: https://chromium-review.googlesource.com/c/1443062Reviewed-by:
-
Michael Starzinger authored
This fixes how the interpreter modifies the operand stack in the case calls with non-zero parameter or return count throw an exception. The interpreter raises the exception before arguments are popped and before results are pushed onto the stack. This makes the control transfer analysis fit this model. It also makes the tests trigger this aspect. R=clemensh@chromium.org TEST=cctest/test-run-wasm-exceptions BUG=v8:8091 Change-Id: I001fc4bc0030393d3c97be3fa9425bc540575071 Reviewed-on: https://chromium-review.googlesource.com/c/1445972 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
When the length is already available from an unrolled iteration (which seems to be the common case), we can just reuse that below for the actual loop. Also it's probably cheaper to always use IntPtr instead of Smi for the length, since that way we don't need expensive SmiConstant for the abort conditions in the unrolled iterations. Change-Id: I322c5d864d58bc56c181473ca8b796a7ab27a51f Reviewed-on: https://chromium-review.googlesource.com/c/1445984Reviewed-by:
-
Maya Lekova authored
R=neis@chromium.org Bug: v8:7790 Change-Id: I41d212129fbdafbf7bc0fdf238f734c6f45ae5df Reviewed-on: https://chromium-review.googlesource.com/c/1445811 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Mathias Bynens authored
This patch changes the parser to allow for-of initializer var-redeclaration of non-destructured catch parameters. Previously, the spec allowed var-redeclaration of a non-destructured catch parameter… try {} catch (e) { var e; } …except in the particular case where the var declaration is a for-of initializer: try {} catch (e) { for (var e of whatever) {} } https://github.com/tc39/ecma262/pull/1393 removes this strange exceptional case. This patch implements that change. BUG=v8:8759 Change-Id: Ia4e33ac1eab89085f8a5fdb547f479cfa38bbee5 Reviewed-on: https://chromium-review.googlesource.com/c/1444954Reviewed-by: -
Marja Hölttä authored
The test defined a function called "Register" which clashes with other functions with the same name. NOTRY=true TBR=sigurds@chromium.org BUG=v8:8179 Change-Id: I7ddfc481cd1de750272de7b43e2e7f9fe26626a9 Reviewed-on: https://chromium-review.googlesource.com/c/1445982Reviewed-by:
-
Ulan Degenbaev authored
Only Heap::GcSafeFindCodeForInnerPointer requires the chunk map. Other large object spaces use more the efficient MemoryChunk::FromAnyPointerAddress. Additionally, this patch renames Register/Unregister to AddPage/RemovePage to be consistent with other spaces and makes them virtual. Bug: chromium:852420 Change-Id: I8d637bb59e15bd61fe452fda7f4a55049d32030c Reviewed-on: https://chromium-review.googlesource.com/c/1439417 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#59207}
-
Stephan Herhut authored
When cleaning up the code for the register allocator, I negated a helper function for readability but forgot to also negate its implementation. For obvious reasons, that was not a good idea. Change-Id: I0e5f4fbf5c83cce8b4891e0a84ef099df15d1ab0 Reviewed-on: https://chromium-review.googlesource.com/c/1445973Reviewed-by:
-
Jakob Gruber authored
Bug: v8:8758 Change-Id: Ifd0c66f27ab5fb33032b243d3a33c0b797b9af17 Reviewed-on: https://chromium-review.googlesource.com/c/1442644 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Marja Hölttä authored
This replaces WeakFactory with FinalizationGroup. New API is here: https://weakrefs.netlify.com/ BUG=v8:8179 Change-Id: I8c1c4a70deb42581d17117423dd29d93bdd35cb0 Reviewed-on: https://chromium-review.googlesource.com/c/1435938Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#59204}
-
Ross McIlroy authored
BUG=v8:8751,v8:8752 Change-Id: Ib99d5b9c399d5f2ab616399fdd3c7f190e2d0399 Reviewed-on: https://chromium-review.googlesource.com/c/1445971Reviewed-by:
-
Jakob Gruber authored
This is an initial step towards clarifying the layout of the instruction area. As follow-ups, we should remove additional safepoint and handler table offset parameters, and perhaps alter Code::safepoint_table_offset (handler_table) semantics to always contain a real offset and avoid the magic 0 signifying nonexistent tables. Bug: v8:8758 Change-Id: I9f54629ff3ddad69904b0e1ce2a58e047397aa15 Reviewed-on: https://chromium-review.googlesource.com/c/1434036 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Tamer Tas authored
Procs return the result by increasing recursion through result_for. This CL eliminates that mechanism from the Processor interface and uses boolen return values for sending tests to signal success or the failure to load the test into the execution queue. R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org Bug: v8:8174,v8:8731 Change-Id: I073a86ca84bcf88da11132b90013d4c8455bc61e Reviewed-on: https://chromium-review.googlesource.com/c/1439239 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Igor Sheludko authored
Currently, in debug mode the snippets check that the result of decompression equals to the full value stored in the field. Bug: v8:7703 Change-Id: I43d20f15510de57582ee00ca23d676dfd4d06636 Reviewed-on: https://chromium-review.googlesource.com/c/1440049Reviewed-by:
-
Michael Starzinger authored
This implements preliminary handling of exceptions thrown by external functions that have been imported into the module. Note that handling internal function is still missing, but tests have been added. R=clemensh@chromium.org TEST=cctest/test-run-wasm-exceptions BUG=v8:8091 Change-Id: I9d07739d8b4715a5643114fd7a868cdd8d72efd0 Reviewed-on: https://chromium-review.googlesource.com/c/1445751 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Bug: chromium:926819 Change-Id: I44832f8707c413d40e5632ed39b97624059f1fba Reviewed-on: https://chromium-review.googlesource.com/c/1445891Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59198}
-
Camillo Bruni authored
We can directly skip the write barrier in the case we set only a Smi. Change-Id: Ic2f4f13f9edb851a18878bec14981a2ad7687433 Reviewed-on: https://chromium-review.googlesource.com/c/1444957Reviewed-by:
-
Andreas Haas authored
We extracted the platform-specific API header into separate, platform- specific header files to avoid OS-specific includes in include/v8.h. As the platform-specific headers are only needed on their specific platform, we did not make them available on other platforms in BUILD.gn. Unfortunately, this is not possible, because the `include` validation in `gn gen --check` checks the availability of header files without considering `#ifdef` in the source files. Therefore the check fails on Windows when the POSIX-specific header file is not available. With this CL platform-specific headers will be generally available. This is no problem because they can only be included on their specific platform anyways. R=adamk@chromium.org Bug: chromium:921971 Change-Id: Iee7cc22063ce31a536f937d73799b7217ac1a94e Reviewed-on: https://chromium-review.googlesource.com/c/1443057Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
-
