- 08 Dec, 2016 37 commits
-
-
gdeepti authored
BUG=chromium:670683 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2548223002 Cr-Commit-Position: refs/heads/master@{#41603}
-
mtrofin authored
When finding conflicts, there's no reason to keep looking for registers that are clearly not going to be available to a candidate live range. BUG=v8:5644 Review-Url: https://codereview.chromium.org/2559733002 Cr-Commit-Position: refs/heads/master@{#41602}
-
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}
-
franzih authored
BUG= Review-Url: https://codereview.chromium.org/2557333002 Cr-Commit-Position: refs/heads/master@{#41598}
-
marja authored
Lowercase 1 character strings occur frequently in minified code. Add a cache for them, so that we don't need to compute the hash + do the hash table lookup for each occurrence. BUG= Review-Url: https://codereview.chromium.org/2541353002 Cr-Commit-Position: refs/heads/master@{#41597}
-
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}
-
ulan authored
needs finalization and allocation limit is reached. BUG= Review-Url: https://codereview.chromium.org/2561103002 Cr-Commit-Position: refs/heads/master@{#41593}
-
hpayer authored
BUG=chromium:648568, chromium:669920 Review-Url: https://codereview.chromium.org/2548213004 Cr-Commit-Position: refs/heads/master@{#41592}
-
jyan authored
https://github.com/ibmruntimes/v8/issues/27 R=joransiu@ca.ibm.com, bjaideep@ca.ibm.com BUG= Review-Url: https://codereview.chromium.org/2561673002 Cr-Commit-Position: refs/heads/master@{#41591}
-
epertoso authored
BUG= Review-Url: https://codereview.chromium.org/2555223002 Cr-Commit-Position: refs/heads/master@{#41590}
-
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}
-
yangguo authored
R=jochen@chromium.org BUG=chromium:617892 Review-Url: https://codereview.chromium.org/2561783002 Cr-Commit-Position: refs/heads/master@{#41587}
-
cbruni authored
Drive-by-fix: support directly loading the results.json from chromeperf. BUG=chromium:672024 NO_TRY=true Review-Url: https://codereview.chromium.org/2555693007 Cr-Commit-Position: refs/heads/master@{#41586}
-
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}
-
bradnelson authored
Using x&(x-1) to check for power of two masks usable at runtime speeds up the life benchmark. Borrowing this from SimplifiedLowering for the AsmJsRemS internal wasm opcode. Leaving this out for general wasm as we should be doing this optimization in LLVM. BUG=v8:4203 TEST=None R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2556963005 Cr-Commit-Position: refs/heads/master@{#41581}
-
petermarshall authored
Speeds up some benchmarks that make heavy use of derived constructors. BUG=chromium:672075 Review-Url: https://codereview.chromium.org/2557963004 Cr-Commit-Position: refs/heads/master@{#41580}
-
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}
-
mtrofin authored
We were losing the stats for the first instance. Recording them as soon as code objects are produced. This way, we have them available for compile-only benchmarks. Review-Url: https://codereview.chromium.org/2556963003 Cr-Commit-Position: refs/heads/master@{#41574}
-
bmeurer authored
First step towards making arguments and rest parameters optimizable by splitting the allocations for the actual object and the elements. The object allocations can already be escape analyzed this way, the elements would need special support in the deoptimizer and the escape analysis, but that can be done as a second separate step. R=jarin@chromium.org BUG=v8:5726 Review-Url: https://codereview.chromium.org/2557283002 Cr-Commit-Position: refs/heads/master@{#41573}
-
yangguo authored
Yes. I thought I was being smart. And yes. It's just a one-liner. TBR=cbruni@chromium.org BUG=chromium:672009 Review-Url: https://codereview.chromium.org/2555213005 Cr-Commit-Position: refs/heads/master@{#41572}
-
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}
-
mgiuca authored
BUG=v8:5725 Review-Url: https://codereview.chromium.org/2559933002 Cr-Commit-Position: refs/heads/master@{#41570}
-
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}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/788dcd7..53448a6 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/415a532..11d3d44 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7f925e3..caccf42 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2555223003 Cr-Commit-Position: refs/heads/master@{#41568}
-
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 3 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}
-
gsathya authored
Previously we created 3 FixedArrays and then filled them up with values. This meant that during the creation of the second and third FixedArray, there were one and two FixedArrays respectively, without any values in it which broke the FixedArrayVerify. This patch fills each FixedArray with the correct values before creating new ones. BUG=chromium:672051 Review-Url: https://codereview.chromium.org/2554323003 Cr-Commit-Position: refs/heads/master@{#41564}
-