- 12 Jan, 2017 5 commits
-
-
jkummerow authored
Revert of Internalize strings in-place (patchset #20 id:380001 of https://codereview.chromium.org/2549773002/ ) Reason for revert: Blocks roll, ASan detects leaking ExternalStrings. Original issue's description: > Internalize strings in-place (reland^2) > > using newly introduced ThinStrings, which store a pointer to the actual, > internalized string they represent. > > BUG=v8:4520 > > (Previously landed as #42168 / af51befe) > (Previously landed as #42193 / 4c699e34) > > Review-Url: https://codereview.chromium.org/2549773002 > Cr-Commit-Position: refs/heads/master@{#42235} > Committed: https://chromium.googlesource.com/v8/v8/+/ec45e6ed2e11698c713e664b1510bc31bcdbbdba TBR=ishell@chromium.org,hpayer@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4520 Review-Url: https://codereview.chromium.org/2626893005 Cr-Commit-Position: refs/heads/master@{#42271}
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2620753003 Cr-Original-Commit-Position: refs/heads/master@{#42258} Committed: https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1cd7cb6 Review-Url: https://codereview.chromium.org/2620753003 Cr-Commit-Position: refs/heads/master@{#42264}
-
verwaest authored
Before the fix it checked whether the initial map of the base constructor pointed back to the new target. That's only true if initial_map->new_target_is_base() (new.target == target). Now it properly checks that the initial map of the original constructor (new.target) was created in combination with target by checking back that new.target->initial_map()->constructor() == target. BUG= Review-Url: https://codereview.chromium.org/2621303003 Cr-Commit-Position: refs/heads/master@{#42263}
-
machenbach authored
Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #7 id:120001 of https://codereview.chromium.org/2620753003/ ) Reason for revert: gc stress: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/8105 also on mac Original issue's description: > [TypeFeedbackVector] Root literal arrays in function literals slots > > Literal arrays and feedback vectors for a function can be garbage > collected if we don't have a rooted closure for the function, which > happens often. It's expensive to come back from this (recreating > boilerplates and gathering feedback again), and the cost is > disproportionate if the function was inlined into optimized code. > > To guard against losing these arrays when we need them, we'll now > create literal arrays when creating the feedback vector for the outer > closure, and root them strongly in that vector. > > BUG=v8:5456 > > Review-Url: https://codereview.chromium.org/2620753003 > Cr-Commit-Position: refs/heads/master@{#42258} > Committed: https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1cd7cb6 TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org,mvstanton@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5456 Review-Url: https://codereview.chromium.org/2626863004 Cr-Commit-Position: refs/heads/master@{#42260}
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2620753003 Cr-Commit-Position: refs/heads/master@{#42258}
-
- 11 Jan, 2017 11 commits
-
-
clemensh authored
Also, add a runtime function to call the interpreter, passing a stack-allocated buffer holding the arguments. The WASM_INTERPRETER_ENTRY stub allocates the stack slot for the arguments, fills it, and calls to the wasm interpreter. It's abi is compatible with WASM functions, such that we can just replace a call to a WASM_FUNCTION with a call to WASM_INTERPRETER_ENTRY. See tracking bug to get the overall picture. BUG=v8:5822 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2619803004 Cr-Commit-Position: refs/heads/master@{#42242}
-
clemensh authored
This will be used to pass parameters of wasm functions to the wasm interpreter. All of them need to be packed into one buffer, which is then passed to the interpreter. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2624183002 Cr-Commit-Position: refs/heads/master@{#42239}
-
ahaas authored
According to the latest spec changes the WasmToJS wrapper and the JSToWasm wrapper through a TypeError if the signature of the wrapper contains a I64 parameter or return value. Originally the TypeError was thrown when the parameter or return value was converted to or from JS. In addition I removed all special handling of I64 parameters and return values in the wrappers which was already dead code. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2626853003 Cr-Commit-Position: refs/heads/master@{#42238}
-
ahaas authored
Original commit message: [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. R=titzer@chromium.org, v8-mips-ports@googlegroups.com Review-Url: https://codereview.chromium.org/2627003002 Cr-Commit-Position: refs/heads/master@{#42237}
-
jkummerow authored
using newly introduced ThinStrings, which store a pointer to the actual, internalized string they represent. BUG=v8:4520 (Previously landed as #42168 / af51befe) (Previously landed as #42193 / 4c699e34) Review-Url: https://codereview.chromium.org/2549773002 Cr-Commit-Position: refs/heads/master@{#42235}
-
ahaas authored
Original commit message: [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. R=titzer@chromium.org, v8-mips-ports@googlegroups.com Review-Url: https://codereview.chromium.org/2628433004 Cr-Commit-Position: refs/heads/master@{#42230}
-
mstarzinger authored
This changes the BytecodeGraphBuilder interface to make the fact that graph construction is independent of a closure explicit. A valid graph can be constructed by providing only the pair of statically known values for SharedFunctionInfo and TypeFeedbackVector. This is in preparation of inlining based on the SharedFunctionInfo. R=jarin@chromium.org BUG=v8:2206 Review-Url: https://codereview.chromium.org/2626623002 Cr-Commit-Position: refs/heads/master@{#42224}
-
clemensh authored
and rename WasmFrame to WasmCompiledFrame. The WasmToInterpreterFrames are not used yet; this will follow in a follow-up CL (see tracking bug for the overall picture). Those frames will represent frames for WASM_TO_INTERPRETER stubs, which call from wasm code to the wasm interpreter, implemented in C++. They will support the Summarize method to inspect the stack frames in the wasm interpreter. R=yangguo@chromium.org, titzer@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2623773004 Cr-Commit-Position: refs/heads/master@{#42213}
-
jkummerow authored
Revert of Internalize strings in-place (patchset #17 id:320001 of https://codereview.chromium.org/2549773002/ ) Reason for revert: blocks roll, see: https://codereview.chromium.org/2628733002/ Debug mode runs into an Abort("External string expected, but not found"). Original issue's description: > Internalize strings in-place (reland) > > using newly introduced ThinStrings, which store a pointer to the actual, > internalized string they represent. > > BUG=v8:4520 > > (Previously landed as #42168 / af51befe. > > Review-Url: https://codereview.chromium.org/2549773002 > Cr-Commit-Position: refs/heads/master@{#42193} > Committed: https://chromium.googlesource.com/v8/v8/+/4c699e349a4986b28574b3a51e8780e3a3d067b1 TBR=ishell@chromium.org,hpayer@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4520 Review-Url: https://codereview.chromium.org/2625073002 Cr-Commit-Position: refs/heads/master@{#42212}
-
franzih authored
Lower StoreDataPropertyInLiteral() when storing computed property names in object literals. Add a new AccessMode, kStoreInLiteral. It is similar to AccessMode::kStore but does not look up properties on the prototype chain. 99% of all literal definitions with computed property names end up with generic access_info because of how we count properties. Once we fix https://bugs.chromium.org/p/v8/issues/detail?id=5625, they'll get lowered as well. BUG=v8:5624 Review-Url: https://codereview.chromium.org/2619773002 Cr-Commit-Position: refs/heads/master@{#42210}
-
zhengxing.li authored
port 0c4b8ff4 (r42192) original commit message: - Refactor Dispatch tables to have separate function, signature tables - New Relocation type for WasmFunctionTableReference, assembler, compiler support. - RelocInfo helper functions for Wasm references BUG= Review-Url: https://codereview.chromium.org/2623133002 Cr-Commit-Position: refs/heads/master@{#42208}
-
- 10 Jan, 2017 10 commits
-
-
bjaideep authored
Port 0c4b8ff4 Original Commit Message: - Refactor Dispatch tables to have separate function, signature tables - New Relocation type for WasmFunctionTableReference, assembler, compiler support. - RelocInfo helper functions for Wasm references R=gdeepti@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2625683004 Cr-Commit-Position: refs/heads/master@{#42201}
-
jkummerow authored
using newly introduced ThinStrings, which store a pointer to the actual, internalized string they represent. BUG=v8:4520 (Previously landed as #42168 / af51befe. Review-Url: https://codereview.chromium.org/2549773002 Cr-Commit-Position: refs/heads/master@{#42193}
-
gdeepti authored
- Refactor Dispatch tables to have separate function, signature tables - New Relocation type for WasmFunctionTableReference, assembler, compiler support. - RelocInfo helper functions for Wasm references Review-Url: https://codereview.chromium.org/2627543003 Cr-Commit-Position: refs/heads/master@{#42192}
-
bradnelson authored
BUG=641885 R=titzer@chromium.org,rossberg@chromium.org Review-Url: https://codereview.chromium.org/2620953002 Cr-Commit-Position: refs/heads/master@{#42190}
-
epertoso authored
BUG= Review-Url: https://codereview.chromium.org/2626603002 Cr-Commit-Position: refs/heads/master@{#42186}
-
ahaas authored
Please take a special look at the code I generate to call the runtime function for the traps. The correct handling of csp vs jssp seems to be quite tricky. Original commit message: [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. R=titzer@chromium.org, georgia.kouveli@arm.com, v8-arm-ports@googlegroups.com Review-Url: https://codereview.chromium.org/2619203005 Cr-Commit-Position: refs/heads/master@{#42181}
-
jochen authored
R=verwaest@chromium.org,epertoso@chromium.org BUG= Review-Url: https://codereview.chromium.org/2620713003 Cr-Commit-Position: refs/heads/master@{#42180}
-
leszeks authored
Node::InputCount() and ::InputAt() have to check for inline/out-of-line inputs every time they are called. The compiler doesn't seem to be very good at caching the result of this check, meaning that it (and all its jumps) would happen for every node access. Previously we would get around this sometimes, by using Node::inputs(), which returned a Node::Inputs iterable over node inputs. However, sometimes node access is more convenient using an index, or we also want to access the count. This patch adds an index accessor and 'count' method to Node::Inputs, and replaces several uses of InputCount and InputAt with this accessor. Review-Url: https://codereview.chromium.org/2617123002 Cr-Commit-Position: refs/heads/master@{#42179}
-
machenbach authored
Revert of Internalize strings in-place (patchset #16 id:300001 of https://codereview.chromium.org/2549773002/ ) Reason for revert: gc stress failures: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/8024 Original issue's description: > Internalize strings in-place > > using newly introduced ThinStrings, which store a pointer to the actual, > internalized string they represent. > > BUG=v8:4520 > > Review-Url: https://codereview.chromium.org/2549773002 > Cr-Commit-Position: refs/heads/master@{#42168} > Committed: https://chromium.googlesource.com/v8/v8/+/af51befe694fe039db3554d4b9165f7d6baceb77 TBR=ishell@chromium.org,hpayer@chromium.org,bmeurer@chromium.org,jkummerow@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4520 Review-Url: https://codereview.chromium.org/2621913002 Cr-Commit-Position: refs/heads/master@{#42170}
-
jkummerow authored
using newly introduced ThinStrings, which store a pointer to the actual, internalized string they represent. BUG=v8:4520 Review-Url: https://codereview.chromium.org/2549773002 Cr-Commit-Position: refs/heads/master@{#42168}
-
- 09 Jan, 2017 9 commits
-
-
rmcilroy authored
Avoid allocating local objects in the outer zone, instead create a new inner zone in ValidatePendingAssessment. BUG=v8:5796 Review-Url: https://codereview.chromium.org/2617413002 Cr-Commit-Position: refs/heads/master@{#42151}
-
mvstanton authored
This changes the NewClosure interface descriptor, but ignores the additional vector/slot arguments for now. The feedback vector gets larger, as it holds a space for each literal array. A follow-on CL will constructively use this space. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2614373002 Cr-Commit-Position: refs/heads/master@{#42146}
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
cbruni authored
The pattern IsNull(isolate) || IsUndefined(isolate) is used in many places all over the code base. Review-Url: https://codereview.chromium.org/2601503002 Cr-Commit-Position: refs/heads/master@{#42138}
-
franzih authored
ToName, ToObject, and ToNumber do not need an eager checkpoint. BUG= Review-Url: https://codereview.chromium.org/2623473002 Cr-Commit-Position: refs/heads/master@{#42136}
-
clemensh authored
We did not associate any position to the stack check in the wasm function prologue, hence a check failed later when trying to map the non-existent position to the asm.js source position. With this CL, we add a mapping to the source position table, mapping the stack check call to byte offset 0 (which is distinct from any valid instruction position). Also, we add another entry to the asm.js source position sidetable, mapping byte offset 0 to the start source position of the function body. R=titzer@chromium.org, ahaas@chromium.org BUG=chromium:677685 Review-Url: https://codereview.chromium.org/2609363004 Cr-Commit-Position: refs/heads/master@{#42130}
-
jgruber authored
The two remaining uses of this intrinsic in debug.js and mirrors.js now simply rely on the runtime function. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2591923003 Cr-Original-Commit-Position: refs/heads/master@{#41892} Committed: https://chromium.googlesource.com/v8/v8/+/c9cb94a06fa7a863d24dd6760b66cecd55748abf Review-Url: https://codereview.chromium.org/2591923003 Cr-Commit-Position: refs/heads/master@{#42128}
-
zhengxing.li authored
X87: Revert of [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms (patchset #3 id:40001 of https://codereview.chromium.org/2605863002/ ). port c16ca32e (r42092) original commit message: Reason for revert: Breaks wasm benchmark (http://crbug.com/v8/5798). Original issue's description: > [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms > > Recognize and emit in-memory comparisons of 8-bit and 16-bit values with > immediate values that fit. > > LOG=N > R=epertoso@chromium.org > > Review-Url: https://codereview.chromium.org/2605863002 > Cr-Commit-Position: refs/heads/master@{#41971} > Committed: https://chromium.googlesource.com/v8/v8/+/be11812c53ff6c8ce320887bc76a3b60d8103695 BUG= Review-Url: https://codereview.chromium.org/2622463002 Cr-Commit-Position: refs/heads/master@{#42126}
-
bmeurer authored
If one input to JSStrictEqual/JSNotStrictEqual is Unique (except InternalizedString) or the hole, then we can turn that into a direct pointer comparison, as such values are only equal to exactly the same unique value. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2611363002 Cr-Commit-Position: refs/heads/master@{#42122}
-
- 06 Jan, 2017 1 commit
-
-
adamk authored
Variables requiring initialization are already forced into ignition, so all the code supporting hole checks in full-codegen and ast-graph-builder is dead. R=bmeurer@chromium.org BUG=v8:5657 Review-Url: https://codereview.chromium.org/2615033002 Cr-Commit-Position: refs/heads/master@{#42112}
-
- 05 Jan, 2017 4 commits
-
-
gsathya authored
This patch adds parsing of spread object property. -- Changes ParsePropertyName to parse Token::ELLIPSIS. -- Throws if rest is encountered by setting a pattern error. -- Adds a new PropertyKind enum (SPREAD) -- Adds a new ObjectLiteralProperty::kind (SPREAD) -- Adds a new harmony-object-spread flag and protects the parser code with it. -- Adds a new runtime function called CopyDataProperties -- Does not add any support for this feature in fullcodegen. -- Ignition calls out to a runtime function CopyDataProperties to perform spread operation. -- Move FastAssign from builtins-objects.cc to objects.cc -- Refactor Builtin_ObjectAssign to use SetOrCopyDataProperties Object rest will be implemented in a follow on patch. BUG=v8:5549 Review-Url: https://codereview.chromium.org/2606833002 Cr-Commit-Position: refs/heads/master@{#42102}
-
rdevlin.cronin authored
BUG=None Review-Url: https://codereview.chromium.org/2609173005 Cr-Commit-Position: refs/heads/master@{#42094}
-
epertoso authored
Revert of [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms (patchset #3 id:40001 of https://codereview.chromium.org/2605863002/ ) Reason for revert: Breaks wasm benchmark (http://crbug.com/v8/5798). Original issue's description: > [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms > > Recognize and emit in-memory comparisons of 8-bit and 16-bit values with > immediate values that fit. > > LOG=N > R=epertoso@chromium.org > > Review-Url: https://codereview.chromium.org/2605863002 > Cr-Commit-Position: refs/heads/master@{#41971} > Committed: https://chromium.googlesource.com/v8/v8/+/be11812c53ff6c8ce320887bc76a3b60d8103695 TBR=danno@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. Review-Url: https://codereview.chromium.org/2618443003 Cr-Commit-Position: refs/heads/master@{#42092}
-
leszeks authored
Add a more efficient encoding for state values that have a large number of optimized-out inputs. Review-Url: https://codereview.chromium.org/2509623002 Cr-Commit-Position: refs/heads/master@{#42088}
-