- 27 Aug, 2015 25 commits
-
-
hpayer authored
BUG=chromium:524425 LOG=n Review URL: https://codereview.chromium.org/1314133004 Cr-Commit-Position: refs/heads/master@{#30423}
-
gdeepti authored
Float32x4, Int32x4, Uint32x4: load, load1, load2, load3 Int16x8, Int8x16, Uint16x8, Uint8x16: load BUG=v8:4124 LOG=N Review URL: https://codereview.chromium.org/1302133002 Cr-Commit-Position: refs/heads/master@{#30422}
-
sergiyb authored
R=machenbach@chromium.org BUG=chromium:511311 LOG=N Review URL: https://codereview.chromium.org/1312953002 Cr-Commit-Position: refs/heads/master@{#30421}
-
mbrandy authored
R=jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1318823006 Cr-Commit-Position: refs/heads/master@{#30420}
-
mbrandy authored
Port 5d875a57 Original commit message: The previous hack with HInstanceOfKnownGlobal was not only slower, but also very brittle and required a lot of weird hacks to support it. And what's even more important it wasn't even correct (because a map check on the lhs is never enough for instanceof). The new implementation provides a sane runtime implementation for InstanceOf plus a fast case in the InstanceOfStub, combined with a proper specialization in the case of a known global in CrankShaft, which does only the prototype chain walk (coupled with a code dependency on the known global). As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf implementation. R=bmeurer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG=v8:4376 LOG=n Review URL: https://codereview.chromium.org/1314263002 Cr-Commit-Position: refs/heads/master@{#30419}
-
mlippautz authored
BUG= Review URL: https://codereview.chromium.org/1319953003 Cr-Commit-Position: refs/heads/master@{#30418}
-
yangguo authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1305163008 Cr-Commit-Position: refs/heads/master@{#30417}
-
titzer authored
R=mstarzinger@chromium.org,yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/1319003002 Cr-Commit-Position: refs/heads/master@{#30416}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/1313383005 Cr-Commit-Position: refs/heads/master@{#30415}
-
mbrandy authored
Port 00df60d1 Original commit message: Makes the following modifications to the interpreter builtins and InterpreterAssembler: - Adds an accumulator register and initializes it to undefined() - Adds a register file pointer register and use it instead of FramePointer to access registers - Modifies builtin to support functions with 0 regiters in the register file - Modifies builtin to Call rather than TailCall to first bytecode handler. R=rmcilroy@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1309113003 Cr-Commit-Position: refs/heads/master@{#30414}
-
mbrandy authored
Port 7fb31bdb Original commit message: The simulator uses a separate JS stack, exhaustion of the C stack however is not caught by JS limit checks. This change now lowers the limit of the JS stack accordingly on function calls. R=mstarzinger@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG=chromium:522380 LOG=n Review URL: https://codereview.chromium.org/1309303005 Cr-Commit-Position: refs/heads/master@{#30413}
-
mstarzinger authored
R=hpayer@chromium.org BUG=v8:1490 LOG=n Review URL: https://codereview.chromium.org/1305163007 Cr-Commit-Position: refs/heads/master@{#30412}
-
hpayer authored
BUG=chromium:525372 LOG=n Review URL: https://codereview.chromium.org/1320893002 Cr-Commit-Position: refs/heads/master@{#30411}
-
cbruni authored
- remove the Backing-Store specific code from builtins.cc and put it in elements.cc. - adding tests to improve coverage of the splice method BUG= Review URL: https://codereview.chromium.org/1312033003 Cr-Commit-Position: refs/heads/master@{#30410}
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1306043003 Cr-Commit-Position: refs/heads/master@{#30409}
-
mstarzinger authored
This makes it clear that only components within the "heap" directory should be friends with the Heap class. The two notable exceptions are Factory and Isolate which represent external interfaces into the heap. R=mlippautz@chromium.org Review URL: https://codereview.chromium.org/1320843002 Cr-Commit-Position: refs/heads/master@{#30408}
-
mlippautz authored
The CompactionSpace is temporarily used during compaction to hold migrated objects. The payload is merged back into the corresponding space after compaction. Note the this is not the complete implementation and it is currently only used in a test. BUG=chromium:524425 LOG=N Review URL: https://codereview.chromium.org/1314493007 Cr-Commit-Position: refs/heads/master@{#30407}
-
rmcilroy authored
BUG=v8:4280 LOG=N TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1319943002 Cr-Commit-Position: refs/heads/master@{#30406}
-
yangguo authored
It has become obsolete since we do the name lookup at compile time. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1319893004 Cr-Commit-Position: refs/heads/master@{#30405}
-
rmcilroy authored
Adds a (currently unused) constant_pool() field to BytecodeArray objects. This field points to a FixedArray object which will be used to hold constants. The BytecodeArray is now a mixed values object type, with the kConstantPoolOffset object holding a tagged pointer, but the remainder of the object holding raw bytes (which could look like tagged pointers but are not). Modify the BytecodeArray GC visitors to deal with this and test that the field is migrated properly when evacuated. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1314953004 Cr-Commit-Position: refs/heads/master@{#30404}
-
rmcilroy authored
Adds support for parameters to the BytecodeArrayBuilder and BytecodeGenerator. Parameters are accessed as negative interpreter registers. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1303403004 Cr-Commit-Position: refs/heads/master@{#30403}
-
yangguo authored
R=bmeurer@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1316943002 Cr-Commit-Position: refs/heads/master@{#30402}
-
mvstanton authored
When vector based stores are on, we don't need to do this anymore. BUG= Review URL: https://codereview.chromium.org/1314433004 Cr-Commit-Position: refs/heads/master@{#30401}
-
mtrofin authored
A few benchmarks, e.g. Massive/SQLite, turn out to be sensitive to compile time. Upon analysis, splinter merging and then splinter creation (splitting) appear to be the main contributors to such regressions. This change tackles main sources of regression in Merging. Profiling SQLite shows, after this change, Merging as noise (down from main C++ contributor of samples) BUG=chromium:1318893002 LOG=n Review URL: https://codereview.chromium.org/1318893002 Cr-Commit-Position: refs/heads/master@{#30400}
-
mtrofin authored
While the intention is to eventually do away with FLAG_turbo_loop_stackcheck and FLAG_turbo_preprocess_range, they are useful for the interim we are still testing and benchmarking the feature. Review URL: https://codereview.chromium.org/1314163003 Cr-Commit-Position: refs/heads/master@{#30399}
-
- 26 Aug, 2015 15 commits
-
-
bradnelson authored
The zone type cache would be handy inside the asm.js typer. Pulling it out into a seperate inlinable header to allow sharing. BUG=https://code.google.com/p/v8/issues/detail?id=4203 TEST=None R=andreas@chromium.org,titzer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1307093006 Cr-Commit-Position: refs/heads/master@{#30398}
-
mbrandy authored
R=jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1315173004 Cr-Commit-Position: refs/heads/master@{#30397}
-
mbrandy authored
Port cbbaf9ea Note that the above commit breaks embedded constant pools and will need to be revised in a future CL. Original commit message: Previously, it was not possible to specify StackSlotOperands for all slots in both the caller and callee stacks. Specifically, the region of the callee's stack including the saved return address, frame pointer, function pointer and context pointer could not be addressed by the register allocator/gap resolver. In preparation for better tail call support, which will use the gap resolver to reconcile outgoing parameters, this change makes it possible to address all slots on the stack, because slots in the previously inaccessible dead zone may become parameter slots for outgoing tail calls. All caller stack slots are accessible as they were before, with slot -1 corresponding to the last stack parameter. Stack slot indices >= 0 access the callee stack, with slot 0 corresponding to the callee's saved return address, 1 corresponding to the saved frame pointer, 2 corresponding to the current function context, 3 corresponding to the frame marker/JSFunction, and slots 4 and above corresponding to spill slots. The following changes were specifically needed: * Frame has been changed to explicitly manage three areas of the callee frame, the fixed header, the spill slot area, and the callee-saved register area. * Conversions from stack slot indices to fp offsets all now go through a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp * The generation of deoptimization translation tables has been changed to support the new stack slot indexing scheme. Crankshaft, which doesn't support the new slot numbering in its register allocator, must adapt the indexes when creating translation tables. * Callee-saved parameters are now kept below spill slots, not above, to support saving only the optimal set of used registers, which is only known after register allocation is finished and spill slots have been allocated. R=danno@chromium.org, titzer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1321553002 Cr-Commit-Position: refs/heads/master@{#30396}
-
mbrandy authored
R=titzer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1315183002 Cr-Commit-Position: refs/heads/master@{#30395}
-
mbrandy authored
Port fe432e1a R=mvstanton@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1321483003 Cr-Commit-Position: refs/heads/master@{#30394}
-
mbrandy authored
Port cd351559 R=mvstanton@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1319763004 Cr-Commit-Position: refs/heads/master@{#30393}
-
mbrandy authored
Port f4c079d4 Original commit message: There's no need to have one InstanceType per SIMD primitive type (this will not scale long-term). Also reduce the amount of code duplication and make it more robust wrt adding new SIMD types. R=bmeurer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1312513004 Cr-Commit-Position: refs/heads/master@{#30392}
-
mbrandy authored
R=yangguo@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1319783002 Cr-Commit-Position: refs/heads/master@{#30391}
-
mbrandy authored
Port b62dbf1e Original commit message: Support for undetectable strings was officially dropped in https://codereview.chromium.org/916753002, but the compilers weren't fixed properly. R=bmeurer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1312473012 Cr-Commit-Position: refs/heads/master@{#30390}
-
mstarzinger authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1314493006 Cr-Commit-Position: refs/heads/master@{#30389}
-
conradw authored
TC39 agreed to disallow "use strict" directives in function body when non-simple parameter lists are used. This is a continuation of caitp's CL https://codereview.chromium.org/1281163002/ with some refactorings removed for now. Still TODO: there is a lot of duplication between the is_simple field of FormalParametersBase and the NonSimpleParameter property ExpressionClassifier keeps track of. It should be possible to remove the former with a minor refactoring of arrow function parsing. This will be attempted in a follow-up CL. BUG= LOG=N Review URL: https://codereview.chromium.org/1300103005 Cr-Commit-Position: refs/heads/master@{#30388}
-
mstarzinger authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1305383003 Cr-Commit-Position: refs/heads/master@{#30387}
-
conradw authored
When encountering a "=" token in ParseAssignmentExpression, the default parameter case is not locally distinguishable from the destructuring case. BUG= Review URL: https://codereview.chromium.org/1317843002 Cr-Commit-Position: refs/heads/master@{#30386}
-
mstarzinger authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1314053003 Cr-Commit-Position: refs/heads/master@{#30385}
-
mstarzinger authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1312413002 Cr-Commit-Position: refs/heads/master@{#30384}
-