- 20 Feb, 2017 26 commits
-
-
Michael Starzinger authored
This reverts commit f967d3e9. Reason for revert: Tanks Mandreel again. Needs investigation. Original change's description: > [turbofan] Handle comparison operations in early lowering. > > This handles comparison operations (equality and relational) having > number feedback during the early type-hint lowering (i.e. during graph > construction). > > R=bmeurer@chromium.org > > Change-Id: I97afd6c0d78a790ce38b731f2532ca18d812a32c > Reviewed-on: https://chromium-review.googlesource.com/444766 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#43315} TBR=mstarzinger@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: Iec335827fe841ac6f1bd45ce095d0a741b2ff5b5 Reviewed-on: https://chromium-review.googlesource.com/445177Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43326}
-
Michael Starzinger authored
This extends the matching of arithmetic operations against the loop induction variable to speculative number operations (on top of the existing JS-level operations). This is needed now that lowering to speculative operations is done during graph construction. R=jarin@chromium.org BUG=chromium:693035 Change-Id: I7c3f71af92b5c059f1d7b3b7f2d3b4a73d7dc43d Reviewed-on: https://chromium-review.googlesource.com/445196Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43325}
-
clemensh authored
All patching logic is now bundled in one compilation unit. The CodeSpecialization object is set up by all relocation and patching that should be applied, and then be run on individual code objects or the whole instance in one go. We hence only need to iterate all relocation tables exactly once at instantiation. Also, we do not patch contexts any more since we do not embed them in generated code any more. R=titzer@chromium.org BUG=v8:5991 Review-Url: https://codereview.chromium.org/2696143006 Cr-Commit-Position: refs/heads/master@{#43324}
-
Caitlin Potter authored
Take runtime path if startIndex parameter requires a ToInteger() call, which can modify the elements kind of the receiver. This removes a stub call from the builtin, and simplifies code slightly. BUG=v8:5986 R=bmeurer@chromium.org, cbruni@chromium.org Change-Id: Id238a81ab8ba28621858004b34d00a4356b8037f Reviewed-on: https://chromium-review.googlesource.com/445006Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#43323}
-
clemensh authored
The generated code for JSToWasm wrappers only depends on the signature of the exported function. Hence, we can reuse the generated code and just patch the reference to the called wasm code. For the unity-wasm benchmark, we reach a hit rate of 98.07% for this cache, and only 395 instead of 20471 wrappers are compiled. This brings down instantiation time from 2.9s to 1.6s on a MBP. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2705993002 Cr-Commit-Position: refs/heads/master@{#43322}
-
tebbi authored
[turbofan] escape analysis bugfixes that got reverted with https://codereview.chromium.org/2680973013/ R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2701403003 Cr-Commit-Position: refs/heads/master@{#43321}
-
Michael Lippautz authored
Bailout didn't happen if we decided to shrink newspace at the end of a Mark-Compact GC. BUG=chromium:693413 Change-Id: Ia4acf565c836b188655773e74083f9151e4ab30b Reviewed-on: https://chromium-review.googlesource.com/445176Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#43320}
-
Michael Lippautz authored
R=ulan@chromium.org BUG=chromium:693413 Change-Id: Ie8e6a5e20e904b81228b67f33c976569e305872c Reviewed-on: https://chromium-review.googlesource.com/445157Reviewed-by:
-
bmeurer authored
Unify the three different implementations of InferReceiverMaps, which were basically copy&paste with slightly different optimizations applied later into a single NodeProperties::InferReceiverMaps helper, which also returns a ZoneHandleSet of maps, rather than only a single map. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2703133003 Cr-Commit-Position: refs/heads/master@{#43318}
-
yangguo authored
Due to link-time optimizations functions with same code can be folded into one, resulting in duplicate references. R=jochen@chromium.org, peria@chromium.org BUG=chromium:617892 Review-Url: https://codereview.chromium.org/2707903002 Cr-Commit-Position: refs/heads/master@{#43317}
-
Michael Lippautz authored
BUG=chromium:693413 Change-Id: I6c6bc62e7f2c702be2462e4b0c3704fabf44f9d2 Reviewed-on: https://chromium-review.googlesource.com/445156 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This handles comparison operations (equality and relational) having number feedback during the early type-hint lowering (i.e. during graph construction). R=bmeurer@chromium.org Change-Id: I97afd6c0d78a790ce38b731f2532ca18d812a32c Reviewed-on: https://chromium-review.googlesource.com/444766Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43315}
-
jgruber authored
info.This returns a Local<Object>, which results in a call to Utils::OpenHandle<JSReceiver>. Casting to a Local<Value> first uses the correct OpenHandle<Object> overload. BUG=chromium:693500 Review-Url: https://codereview.chromium.org/2706833002 Cr-Commit-Position: refs/heads/master@{#43314}
-
Toon Verwaest authored
By now lazy allocation of block scopes probably doesn't make that much sense anymore, since the memory overhead significantly reduced. Not indirecting scope() over ScopeState is faster, which is more important at this point. BUG=v8:5209 Change-Id: I2968f01252769e7b1198a0a0876765a06ab0d3bd Reviewed-on: https://chromium-review.googlesource.com/445025Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43313}
-
titzer authored
R=ahaas@chromium.org, mythria@chromium.org BUG= Review-Url: https://codereview.chromium.org/2702123003 Cr-Commit-Position: refs/heads/master@{#43312}
-
Marja Hölttä authored
BUG=v8:5516 R=vogelheim@chromium.org Change-Id: I7a39e49cc569b87064e5ac6764f4e3a65b2c6d11 Reviewed-on: https://chromium-review.googlesource.com/444765Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43311}
-
titzer authored
This makes it easier to implement asynchronous compilation by hiding all the implementation details of both synchronous and asynchronous compilation within wasm-module.cc, whereas before the code in wasm-js.cc actually implemented asynchronous compilation in terms of synchronous. BUG= Review-Url: https://codereview.chromium.org/2695813005 Cr-Commit-Position: refs/heads/master@{#43310}
-
dcheng authored
BUG=693695 Review-Url: https://codereview.chromium.org/2702123002 Cr-Commit-Position: refs/heads/master@{#43309}
-
danno authored
Revert of [interpreter] Create custom call opcodes for specific argument counts (patchset #13 id:240001 of https://codereview.chromium.org/2684993002/ ) Reason for revert: Due to arm64 failures Original issue's description: > [interpreter] Create custom call opcodes for specific argument counts > > Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1, > and CallProperty2. Also share the bytecode handler code between between > equivalent CallX and CallPropertyX handlers. > > Review-Url: https://codereview.chromium.org/2684993002 > Cr-Commit-Position: refs/heads/master@{#43290} > Committed: https://chromium.googlesource.com/v8/v8/+/00d6f1f80a00c4ac398af588dbd6815395791015 TBR=rmcilroy@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. Review-Url: https://codereview.chromium.org/2709533002 Cr-Commit-Position: refs/heads/master@{#43308}
-
Toon Verwaest authored
BUG= Change-Id: Ib7cc2a04a7c8e314e1f4a8720eef569a6a4a3b18 Reviewed-on: https://chromium-review.googlesource.com/444406Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
dcheng authored
Remote objects don't have a creation context. BUG=527190 Review-Url: https://codereview.chromium.org/2693203003 Cr-Commit-Position: refs/heads/master@{#43306}
-
Igor Sheludko authored
BUG= Change-Id: Ib82400e3a1b9d58257b26b8a5d7d22f5822d7a6c Reviewed-on: https://chromium-review.googlesource.com/445084Reviewed-by:
-
Igor Sheludko authored
The constant field tracking is still disabled. BUG=v8:5495 Change-Id: I543fe50b82e2255bbf200ea785ec53e3623e30cb Reviewed-on: https://chromium-review.googlesource.com/440924 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
hablich authored
Revert of [wasm] Embedder can control what buffers wasm compilation works on. (patchset #3 id:60001 of https://codereview.chromium.org/2699843003/ ) Reason for revert: Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/16427 Original issue's description: > [wasm] Embedder can control what buffers wasm compilation works on. > > Two controls, one for instantiation and one for compilation. They allow > the embedder (e.g. Chrome) check properties of the parameters of those > two operations, and decide if they are allowed to continue. > > For example, Chrome may now decline compilation of certain size buffers, > in synchronous cases; same for instantiation (where the buffer size > refers to the size of the buffer containing wasm wire bytes) > > BUG=v8:5981 > > Review-Url: https://codereview.chromium.org/2699843003 > Cr-Commit-Position: refs/heads/master@{#43295} > Committed: https://chromium.googlesource.com/v8/v8/+/d9bc0ffb16e633d52d7bcfd547a6125f0e4dfb87 TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5981 Review-Url: https://codereview.chromium.org/2701413002 Cr-Commit-Position: refs/heads/master@{#43303}
-
hablich authored
Revert of [wasm] Identify wasm functions with index into the function tables. (patchset #7 id:110001 of https://codereview.chromium.org/2690113012/ ) Reason for revert: Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/13707 Original issue's description: > [wasm] Identify wasm functions with index into the function tables. > > Currently, the default name for wasm functions in generated code is 'wasm', tag wasm functions with the index into the function table to identify functions. Snippets of sample output with --print-code below. > > Before: > --- Code --- > kind = WASM_FUNCTION > name = wasm > compiler = turbofan > > After: > --- Code --- > kind = WASM_FUNCTION > name = wasm#200 > compiler = turbofan > > R=mtrofin@chromium.org > > Review-Url: https://codereview.chromium.org/2690113012 > Cr-Commit-Position: refs/heads/master@{#43296} > Committed: https://chromium.googlesource.com/v8/v8/+/5fc3ac29e4d942ccb4c45f6cdcee75d0b394b296 TBR=mtrofin@chromium.org,gdeepti@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. Review-Url: https://codereview.chromium.org/2708593002 Cr-Commit-Position: refs/heads/master@{#43302}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/6d17aae..3e739fd TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: Ibb3a878d44b3fd56e95bbfa608500761c882bd21 Reviewed-on: https://chromium-review.googlesource.com/444426Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#43301}
-
- 19 Feb, 2017 2 commits
-
-
Georg Neis authored
The bytecode generator did not necessarily know for which scope, and thus language mode, it was generating code, because it only tracked scopes that have a context. This led to wrong behavior in some examples involving class expressions (which are always in strict mode). With this CL, the bytecode generator explicitly tracks the current scope, independent of whether it has a context. BUG=v8:5927 Change-Id: Ifa6b3ee5e13e07b63d00e74c7f557a328633c88b Reviewed-on: https://chromium-review.googlesource.com/444785 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#43300}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/35fe3e2..6d17aae Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/36a5082..84a7af6 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: I102ea8b7361db854fcdd736e5e392f25690e0b1b Reviewed-on: https://chromium-review.googlesource.com/444507Reviewed-by:
-
- 18 Feb, 2017 4 commits
-
-
vabr authored
Currently, typeof o, where o is an undetectable callable object (such as document.all), returns 'function' if optimised. It should, however, return 'undefined'. This CL excludes undetectable objects from the optimization resulting in type 'function' and renames the related code to reflect that. BUG=v8:5972 R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2697063002 Cr-Commit-Position: refs/heads/master@{#43298}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1ecc6e7..35fe3e2 Rolling v8/test/wasm-js: https://chromium.googlesource.com/external/github.com/WebAssembly/spec/+log/b96d096..193fcb4 Rolling v8/tools/swarming_client: https://chromium.googlesource.com/external/swarming.client/+log/ebc8dab..11e31af TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Change-Id: Ice84eb04c8cad9444b7062826cb7dd422e862dd3 Reviewed-on: https://chromium-review.googlesource.com/444506Reviewed-by:
-
gdeepti authored
Currently, the default name for wasm functions in generated code is 'wasm', tag wasm functions with the index into the function table to identify functions. Snippets of sample output with --print-code below. Before: --- Code --- kind = WASM_FUNCTION name = wasm compiler = turbofan After: --- Code --- kind = WASM_FUNCTION name = wasm#200 compiler = turbofan R=mtrofin@chromium.org Review-Url: https://codereview.chromium.org/2690113012 Cr-Commit-Position: refs/heads/master@{#43296}
-
mtrofin authored
Two controls, one for instantiation and one for compilation. They allow the embedder (e.g. Chrome) check properties of the parameters of those two operations, and decide if they are allowed to continue. For example, Chrome may now decline compilation of certain size buffers, in synchronous cases; same for instantiation (where the buffer size refers to the size of the buffer containing wasm wire bytes) BUG=v8:5981 Review-Url: https://codereview.chromium.org/2699843003 Cr-Commit-Position: refs/heads/master@{#43295}
-
- 17 Feb, 2017 8 commits
-
-
gsathya authored
Adds five new TF builtins for the spec defined functions/closures. This follows mechanism similar to promise resolving functions approach where we store the closure variables in a custom context. Adds a new --harmony-promise-finally flag. BUG=v8:5967 Review-Url: https://codereview.chromium.org/2695753002 Cr-Commit-Position: refs/heads/master@{#43294}
-
bmeurer authored
Failed instance migration should only be reported if the map of the object was originally marked as deprecated. Otherwise it's pretty confusing to investigate deoptimizations. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2700143002 Cr-Commit-Position: refs/heads/master@{#43293}
-
binji authored
BUG=v8:5906 R=machenbach@chromium.org Review-Url: https://codereview.chromium.org/2697723004 Cr-Commit-Position: refs/heads/master@{#43292}
-
Georg Neis authored
Until recently, it sometimes did. BUG= Change-Id: I8785c1865909e6f46693b71c9146d4fa17114fce Reviewed-on: https://chromium-review.googlesource.com/444188 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
-
danno authored
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1, and CallProperty2. Also share the bytecode handler code between between equivalent CallX and CallPropertyX handlers. Review-Url: https://codereview.chromium.org/2684993002 Cr-Commit-Position: refs/heads/master@{#43290}
-
eholk authored
This is the beginning of a new fuzzer that generates correct-by-construction Wasm modules. This should allow us to better exercise the compiler and correctness aspects of fuzzing. It is based off of ahaas' original Wasm fuzzer. At the moment, it can generate expressions made up of most binops, and also nested blocks with unconditional breaks. Future CLs will add additional constructs, such as br_if, loops, memory access, etc. The way the fuzzer works is that it starts with an array of arbitrary data provided by libfuzzer. It uses the data to generate an expression. Care is taken to make use of the entire string. Basically, the generator has a bunch of grammar-like rules for how to construct an expression of a given type. For example, an i32 can be made by adding two other i32s, or by wrapping an i64. The process then continues recursively until all the data is consumed. We generate an expression from a slice of data as follows: * If the slice is less than or equal to the size of the type (e.g. 4 bytes for i32), then it will emit the entire slice as a constant. * Otherwise, it will consume the first 4 bytes of the slice and use this to select which rule to apply. Each rule then consumes the remainder of the slice in an appropriate way. For example: * Unary ops use the remainder of the slice to generate the argument. * Binary ops consume another four bytes and mod this with the length of the remaining slice to split the slice into two parts. Each of these subslices are then used to generate one of the arguments to the binop. * Blocks are basically like a unary op, but a stack of block types is maintained to facilitate branches. For blocks that end in a break, the first four bytes of a slice are used to select the break depth and the stack determines what type of expression to generate. The goal is that once this generator is complete, it will provide a one to one mapping between binary strings and valid Wasm modules. Review-Url: https://codereview.chromium.org/2658723006 Cr-Commit-Position: refs/heads/master@{#43289} -
Igor Sheludko authored
BUG= Change-Id: Ifc441739ef730a0b2278be0b662413c223631a72 Reviewed-on: https://chromium-review.googlesource.com/444190Reviewed-by:
-
bjaideep authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2698333003 Cr-Commit-Position: refs/heads/master@{#43287}
-
