- 09 Dec, 2016 9 commits
-
-
bradnelson authored
BUG=672785 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2566683002 Cr-Commit-Position: refs/heads/master@{#41624}
-
mstarzinger authored
This fixes the corner-case where the method in question failed to lookup the very last deoptimization bailout without subsequent entries within the relocation info. Also enable a test covering this. R=tebbi@chromium.org TEST=cctest/test-cpu-profiler/CollectDeoptEvents Review-Url: https://codereview.chromium.org/2565733002 Cr-Commit-Position: refs/heads/master@{#41623}
-
bradnelson authored
Because the parser optimizes !123 -> false, we allow booleans in expressions (but not parameter annotations). Allow this in asm-wasm-builder. Turn on an early out case in asm-typer that is fine. BUG=672784 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2561193003 Cr-Commit-Position: refs/heads/master@{#41622}
-
mstarzinger authored
By now the predicate in question is an exact negation of %IsAsmWasmCode as the name intuitively implies. The need for two separate test methods no longer exists and one of the two can be removed. R=bradnelson@chromium.org Review-Url: https://codereview.chromium.org/2562003002 Cr-Commit-Position: refs/heads/master@{#41616}
-
mstarzinger authored
By now the compiler pipeline will not produce optimized code for asm.js functions unless validation failed (even when --always-opt is enabled). The related workaround in the testing predicate can be removed. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2549463002 Cr-Commit-Position: refs/heads/master@{#41614}
-
clemensh authored
In the asm.js code translated to wasm, we call imported functions via a WASM_TO_JS stub, which first calls the function and then calls ToNumber on the return value. Exceptions can happen in both calls. We were only ever reporting the location of the function call, whereas asm.js code executed via turbofan reported the location of the type coercion operator ("+" on "+foo()" or "|" on "foo()|0"). This CL implements the same behaviour for asm.js code translated to wasm. The following is changed: - the AsmWasmBuilder records the parent node when descending on a binary operator (also "+foo()" is represented by a binary operation). - it stores not one location per call in the source position side table, but two (one for the call, one for the parent which does the type coercion). - the wasm compiler annotates the source positions "0" and "1" to the two calls in the WASM_TO_JS wrapper (only if the module origin is asm.js). - the StackFrame::State struct now also holds the callee_pc_address, which is set in ComputeCallerState. The WASM frame uses this information to determine whether the callee frame is WASM_TO_JS, and whether that frame is at the ToNumber conversion call. - the same information is also stored in the FrameArray which is used to reconstruct the stack trace later. R=titzer@chromium.org, bradnelson@chromium.org CC=jgruber@chromium.org BUG=v8:4203,v8:5724 Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262 Review-Url: https://codereview.chromium.org/2555243002 Cr-Original-Commit-Position: refs/heads/master@{#41599} Cr-Commit-Position: refs/heads/master@{#41613}
-
mstarzinger authored
The deserialization of the {Scope::asm_module} predicate relies on a context being present for such modules. This ensures we always allocate such a context, even in cases where no variables are allocated in it. R=neis@chromium.org TEST=cctest/test-parsing/AsmModuleFlag BUG=v8:5653 Review-Url: https://codereview.chromium.org/2561103004 Cr-Commit-Position: refs/heads/master@{#41611}
-
yangguo authored
R=jgruber@chromium.org BUG=v8:5510 Review-Url: https://codereview.chromium.org/2557043005 Cr-Commit-Position: refs/heads/master@{#41610}
-
gsathya authored
This will be used in CSA to check if any promisehook is set. -- Adds a is_promisehook_enabled_ field to the isolate and helper methods. -- Adds this field to the ExternalReference table. -- Adds a helper method to access this from CSA Note -- this patch doesn't actually add the ability to attach the hook yet. BUG=v8:4643 Review-Url: https://codereview.chromium.org/2566483002 Cr-Commit-Position: refs/heads/master@{#41607}
-
- 08 Dec, 2016 21 commits
-
-
gdeepti authored
BUG=chromium:670683 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2548223002 Cr-Commit-Position: refs/heads/master@{#41603}
-
clemensh authored
Revert of [wasm] Fix location for error in asm.js ToNumber conversion (patchset #5 id:80001 of https://codereview.chromium.org/2555243002/ ) Reason for revert: gc-stress failures Original issue's description: > [wasm] Fix location for error in asm.js ToNumber conversion > > In the asm.js code translated to wasm, we call imported functions via a > WASM_TO_JS stub, which first calls the function and then calls ToNumber > on the return value. Exceptions can happen in both calls. > We were only ever reporting the location of the function call, whereas > asm.js code executed via turbofan reported the location of the type > coercion operator ("+" on "+foo()" or "|" on "foo()|0"). > > This CL implements the same behaviour for asm.js code translated to > wasm. The following is changed: > - the AsmWasmBuilder records the parent node when descending on a binary > operator (also "+foo()" is represented by a binary operation). > - it stores not one location per call in the source position side > table, but two (one for the call, one for the parent which does the > type coercion). > - the wasm compiler annotates the source positions "0" and "1" to the > two calls in the WASM_TO_JS wrapper (only if the module origin is > asm.js). > - during stack trace generation (in the StackTraceIterator), when we > move from the WASM_TO_JS frame to the WASM frame, we remember at which > call inside the WASM_TO_JS wrapper we are, and encode this information > in the generated caller state, used for the WASM frame. > - the same information is also stored in the FrameArray which is used > to reconstruct the stack trace later. > > R=titzer@chromium.org, bradnelson@chromium.org > CC=jgruber@chromium.org > BUG=v8:4203,v8:5724 > > Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262 > Cr-Commit-Position: refs/heads/master@{#41599} TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4203,v8:5724 Review-Url: https://codereview.chromium.org/2563613003 Cr-Commit-Position: refs/heads/master@{#41601}
-
jochen authored
Now that SharedFunctionInfos have a unique ID (and the IDs are dense), we can use them as an index into an array, instead of using a WeakFixedArray where we have to do a linear scan. Hooking up liveedit is a bit more involved, see https://docs.google.com/presentation/d/1FtNa3U7WsF5bPhY9uGoJG5Y9hnz5VBDabfOWpb4unWI/edit for an overview BUG=v8:5589 R=verwaest@chromium.org,jgruber@chromium.org Review-Url: https://codereview.chromium.org/2547483002 Cr-Commit-Position: refs/heads/master@{#41600}
-
clemensh authored
In the asm.js code translated to wasm, we call imported functions via a WASM_TO_JS stub, which first calls the function and then calls ToNumber on the return value. Exceptions can happen in both calls. We were only ever reporting the location of the function call, whereas asm.js code executed via turbofan reported the location of the type coercion operator ("+" on "+foo()" or "|" on "foo()|0"). This CL implements the same behaviour for asm.js code translated to wasm. The following is changed: - the AsmWasmBuilder records the parent node when descending on a binary operator (also "+foo()" is represented by a binary operation). - it stores not one location per call in the source position side table, but two (one for the call, one for the parent which does the type coercion). - the wasm compiler annotates the source positions "0" and "1" to the two calls in the WASM_TO_JS wrapper (only if the module origin is asm.js). - during stack trace generation (in the StackTraceIterator), when we move from the WASM_TO_JS frame to the WASM frame, we remember at which call inside the WASM_TO_JS wrapper we are, and encode this information in the generated caller state, used for the WASM frame. - the same information is also stored in the FrameArray which is used to reconstruct the stack trace later. R=titzer@chromium.org, bradnelson@chromium.org CC=jgruber@chromium.org BUG=v8:4203,v8:5724 Review-Url: https://codereview.chromium.org/2555243002 Cr-Commit-Position: refs/heads/master@{#41599}
-
Ilija.Pavlovic authored
Fix 7a6f294f. The first correction enables correct execution DoMathMinMax when two input registers are the same register. The second correction adds NOP instructions after branch instructions in tests macro_float_minmaxf(32|64). TEST=cctest/test-macro-assembler-mips[64]/macro_float_minmax_f32 cctest/test-macro-assembler-mips[64]/macro_float_minmax_f64 mjsunit/regress/math-min BUG= Review-Url: https://codereview.chromium.org/2556793003 Cr-Commit-Position: refs/heads/master@{#41596}
-
bradnelson authored
We have been assuming in several places that ContainsDot or ToInt32 is sufficient to check a value is a valid double or int. Refactoring all the checks to one place and making them cope with booleans or other unexpected types being present. BUG=672044 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2555323003 Cr-Commit-Position: refs/heads/master@{#41595}
-
bradnelson authored
Use of eval in a function wraps it in a context. This throws off assumptions not checked until later, which is at odds with incremental validation and conversion. Check that module parameters are PARAMETER location early. BUG=672045 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2558813004 Cr-Commit-Position: refs/heads/master@{#41594}
-
leszeks authored
Wrap the liveness bitvectors from the bytecode liveness analysis with a helper class, which makes the register/accumulator bits explicit. Review-Url: https://codereview.chromium.org/2552723004 Cr-Commit-Position: refs/heads/master@{#41589}
-
yangguo authored
Aside from the default snapshot, there is no need for additional context snapshots to have the ability to replace the global proxy and global object after deserialization. Changes include: - Changes to the API to better distinguish default context snapshot from additional context snapshots. - Disallow global handles when creating snapshots. - Allow extensions when creating snapshots. This solves the issue of not being able to having accessors and interceptors on the global object of contexts to be serialized. R=jochen@chromium.org, peria@chromium.org BUG=chromium:617892 Review-Url: https://codereview.chromium.org/2557743003 Cr-Commit-Position: refs/heads/master@{#41588}
-
ishell authored
All accessor IC stubs now pass the verification. BUG= Review-Url: https://codereview.chromium.org/2556123002 Cr-Commit-Position: refs/heads/master@{#41585}
-
mvstanton authored
The patch was reverted due to a bug - we failed to evict OSR-optimized code in the case where the SharedFunctionInfo OptimizedCodeMap was empty/cleared. Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. Review-Url: https://codereview.chromium.org/2561083002 Cr-Commit-Position: refs/heads/master@{#41584}
-
rmcilroy authored
BUG=v8:5723 Review-Url: https://codereview.chromium.org/2555263002 Cr-Commit-Position: refs/heads/master@{#41583}
-
neis authored
This CL attempts to set the maybe-assigned flag for variables that are written to as part of a destructuring or loop header. For instance, in the following two cases we now mark x as maybe-assigned. a) [x] = [1]; b) for (x of [1,2,3]) {}; There's more work to do here, this is just a first step. R=adamk@chromium.org, mstarzinger@chromium.org BUG=v8:5636 Review-Url: https://codereview.chromium.org/2562443003 Cr-Commit-Position: refs/heads/master@{#41582}
-
mstarzinger authored
R=bmeurer@chromium.org,titzer@chromium.org Review-Url: https://codereview.chromium.org/2557693006 Cr-Commit-Position: refs/heads/master@{#41579}
-
qiuyi.zqy authored
Currently when the number passed to TryNumberToSize is 1 << 64, it gets away with a bug caused by rounding of mantissa. Then the number will be casted to 0 and TryNumberToSize will return true. This patch fix this by making the range check more accurate. BUG=v8:5712 Review-Url: https://codereview.chromium.org/2548243004 Cr-Commit-Position: refs/heads/master@{#41578}
-
neis authored
R=adamk@chromium.org, mstarzinger@chromium.org BUG= Review-Url: https://codereview.chromium.org/2554363002 Cr-Commit-Position: refs/heads/master@{#41577}
-
bradnelson authored
BUG=672047 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2555203002 Cr-Commit-Position: refs/heads/master@{#41576}
-
adamk authored
As of https://github.com/tc39/ecma262/commit/13906140a, the spec now returns true when [[SetPrototypeOf]] is invoked with null on a module namespace object. R=neis@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2557923004 Cr-Commit-Position: refs/heads/master@{#41575}
-
bmeurer authored
Revert of Store OSR'd optimized code on the native context. (patchset #8 id:140001 of https://codereview.chromium.org/2549753002/ ) Reason for revert: Speculative revert WebGL breakage reported in https://bugs.chromium.org/p/chromium/issues/detail?id=672367 Original issue's description: > Store OSR'd optimized code on the native context. > > Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. > > BUG= > > Committed: https://crrev.com/378b6b22fb7925ac5b672335a54599f5739e7758 > Cr-Commit-Position: refs/heads/master@{#41554} TBR=mstarzinger@chromium.org, mvstanton@chromium.org, ulan@chromium.org BUG= Review-Url: https://codereview.chromium.org/2562623003 Cr-Commit-Position: refs/heads/master@{#41571}
-
gsathya authored
-- Moves promiseHasHandlerSymbol to inobject property -- Ports PromiseResolveClosure to TF -- Fix a non spec async-await test which fails now because we do a map check for native promise check (instead of IsPromise). Changing the constructor (in the test) invalidates the map check. This patch results in a 7.1% performance improvement in the bluebird benchmark (over 5 runs). BUG=v8:5343 Review-Url: https://codereview.chromium.org/2541283002 Cr-Commit-Position: refs/heads/master@{#41569}
-
lpy authored
jasongin@ created this patch. https://github.com/jasongin/nodejs/commit/dcc50445a364664586164f42f9250732bd372982 This patch adds the support to emit a trace event by using a comma-separated list of categories, so that the trace event will be emitted if there is at least one category is enabled in the categories list. TBR=jochen@chromium.org Review-Url: https://codereview.chromium.org/2558193002 Cr-Commit-Position: refs/heads/master@{#41567}
-
- 07 Dec, 2016 10 commits
-
-
luoe authored
Due to the isOwn check, functions inherited through prototype will not be included in a preview. BUG=645053 Review-Url: https://codereview.chromium.org/2554623003 Cr-Commit-Position: refs/heads/master@{#41566}
-
luoe authored
Getter properties are not currently included in the protocol's Runtime.ObjectPreview. DevTools currently shows getter properties when evaluating arrays in the console, and this CL brings them into the preview generated for RemoteObjects. Corresponding DevTools CL: https://codereview.chromium.org/2521513006/ BUG=666882 Review-Url: https://codereview.chromium.org/2508423002 Cr-Commit-Position: refs/heads/master@{#41565}
-
jwolfe authored
We're still collecting use counter data for this situation. BUG=v8:4973 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2510873005 Cr-Commit-Position: refs/heads/master@{#41563}
-
jwolfe authored
When an octal escape sequence is in a string in strict mode: - Octal literals are not allowed in strict mode. + Octal escape sequences are not allowed in strict mode. When an octal escape sequence is in a template string: - Octal literals are not allowed in template strings. + Octal escape sequences are not allowed in template strings. BUG=v8:4973 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2551633002 Cr-Commit-Position: refs/heads/master@{#41560}
-
bradnelson authored
The asm.js spec requires exports to be identifiers, this was DCHECKED in the asm-wasm-builder, but not the typer. BUG=672046 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2552913004 Cr-Commit-Position: refs/heads/master@{#41557}
-
dcheng authored
When v8 fails an access check, it invokes a helper to try to see if it can service the request via an access check interceptor. Invoking the access check interceptor can throw an exception (e.g. a SecurityError). Unfortunately, the failed access check property helpers and the interceptor helpers don't agree on how to propagate the exception: if the interceptor helper detects a scheduled exception, it promotes the exception to a pending exception and returns to the failed access check property helper. The failed access check property helper also has an early return in case of a scheduled exception. However, this doesn't work, as the previously thrown exception is no longer scheduled, as it's been promoted to a pending exception. Thus, the failed access check property helper always end up calling the failed access check callback as well. Since Blink's implementation of the failed access check callback also throws an exception, this conflicts with the previously-thrown, already-pending exception. With this patch, the failed access check property helpers check for a pending exception rather than a scheduled exception after invoking the interceptor, so the exception can be propagated correctly. BUG=v8:5715 R=yangguo@chromium.org,jochen@chromium.org Review-Url: https://codereview.chromium.org/2550423002 Cr-Commit-Position: refs/heads/master@{#41556}
-
caitp authored
Introduces: - a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions. - a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan. The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST. This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value. BUG=v8:4280 R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.org TBR=rossberg@chromium.org Review-Url: https://codereview.chromium.org/2557593004 Cr-Commit-Position: refs/heads/master@{#41555}
-
mvstanton authored
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. BUG= Review-Url: https://codereview.chromium.org/2549753002 Cr-Commit-Position: refs/heads/master@{#41554}
-
clemensh authored
There were two bugs, one partly hiding the other one: 1) We generate the ToNumber conversion for each WASM_TO_JS wrapper, even if the expected return type is void. 2) The return node in the WASM_TO_JS wrapper did not use the effect of the ToNumber conversion. This CL fixes both, and adds test cases to check that we do throw an error trying to convert (e.g.) Symbol to a number, but only if the return type is not void. Additional test check that a user-provided valueOf method is actually called the correct number of times. R=titzer@chromium.org, bradnelson@chromium.org BUG=v8:4203 Review-Url: https://codereview.chromium.org/2552123004 Cr-Commit-Position: refs/heads/master@{#41552}
-
yangguo authored
R=jgruber@chromium.org, kozyatinskiy@chromium.org BUG=v8:5510 Review-Url: https://codereview.chromium.org/2530093002 Cr-Commit-Position: refs/heads/master@{#41549}
-