- 21 Aug, 2015 24 commits
-
-
Michael Hablich authored
BUG= TBR=vogelheim@chromium.org,yangguo@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1304203002 . Cr-Commit-Position: refs/heads/master@{#30302}
-
mlippautz authored
BUG= Review URL: https://codereview.chromium.org/1293283003 Cr-Commit-Position: refs/heads/master@{#30301}
-
mstarzinger authored
R=yangguo@chromium.org,hpayer@chromium.org Review URL: https://codereview.chromium.org/1306053003 Cr-Commit-Position: refs/heads/master@{#30300}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/1296713007 Cr-Commit-Position: refs/heads/master@{#30299}
-
wingo authored
BUG=v8:4211 LOG=Y R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1286383005 Cr-Commit-Position: refs/heads/master@{#30298}
-
chunyang.dai authored
port cd351559 (r30284). original commit message: BUG= Review URL: https://codereview.chromium.org/1303223002 Cr-Commit-Position: refs/heads/master@{#30297}
-
chunyang.dai authored
port fe432e1a (r30250). original commit message: BUG= Review URL: https://codereview.chromium.org/1303973004 Cr-Commit-Position: refs/heads/master@{#30296}
-
rossberg authored
This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here, let x = 1; function f(g = () => x) { var y eval("var x = 2") return g() + x // f() = 3 } we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body: - Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object. - When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo). - While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum. - Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object. - Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts. - In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings. - In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope. - ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain. - Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface. - While at it, refactor and unify some respective code in the debugger. Sorry, this CL is large. I could try to split it up, but everything is rather entangled. @mstarzinger: Please review the changes to contexts. @yangguo: Please have a look at the debugger stuff. R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:811,v8:2160 LOG=N Review URL: https://codereview.chromium.org/1292753007 Cr-Commit-Position: refs/heads/master@{#30295}
-
rossberg authored
- Introduce a proper bit for SIMD primitive values. - Introduce constructors for individual SIMD types. These are currently just classes, which seems good enough for now, given that we always have exactly one global map per SIMD type. The only problem with using class types for SIMD is that a SIMD constant won't be a subtype of its specific type, only of the general SIMD type. But until we actually introduce SIMD constants into the compiler that shouldn't matter. R=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/1303863002 Cr-Commit-Position: refs/heads/master@{#30294}
-
chunyang.dai authored
port d0bacc61 (r30235). original commit message: BUG= Review URL: https://codereview.chromium.org/1286123008 Cr-Commit-Position: refs/heads/master@{#30293}
-
chunyang.dai authored
port cbbaf9ea (r30224). original commit message: [turbofan] Unify referencing of stack slots 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. BUG= Review URL: https://codereview.chromium.org/1293103003 Cr-Commit-Position: refs/heads/master@{#30292}
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1302293002 Cr-Commit-Position: refs/heads/master@{#30291}
-
chunyang.dai authored
port 0492bb32 (r30203). original commit message: BUG= Review URL: https://codereview.chromium.org/1306833002 Cr-Commit-Position: refs/heads/master@{#30290}
-
chunyang.dai authored
port 00df60d1 (r30219). 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. BUG= Review URL: https://codereview.chromium.org/1304593002 Cr-Commit-Position: refs/heads/master@{#30289}
-
chunyang.dai authored
port f4c079d4 (r30107). This is the appendix of 458dfe3b943edb3238917edfe9e2dde326cd1adb which misses one modified file. 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. BUG= Review URL: https://codereview.chromium.org/1304963003 Cr-Commit-Position: refs/heads/master@{#30288}
-
mlippautz authored
BUG=chromium:520607 LOG=N Review URL: https://codereview.chromium.org/1302273002 Cr-Commit-Position: refs/heads/master@{#30287}
-
wingo authored
Not all parenthesized AssignmentExpressions whose components are valid binding patterns are valid arrow function formal parameters. In particular (a,b,c)() is not valid, and in general the existing code wasn't catching the tail productions of ConditionalExpression, BinaryExpression, PostfixExpression, LeftHandSideExpression, and MemberExpression. Thanks to Adrian Perez for the test case. BUG=v8:4211 LOG=Y R=rossberg@chromium.org Review URL: https://codereview.chromium.org/1306583002 Cr-Commit-Position: refs/heads/master@{#30286}
-
yangguo authored
We can use the script type to determine that instead. Script of type TYPE_NATIVE are considered builtins, TYPE_NORMAL are not. The only exception to this rule is the empty function, for which the script is TYPE_NATIVE (observable by the debugger), but should be stringified to "function () {}" instead of "function () { [native code] }". For this, I introduce a hide_source flag on the script object. We also use IsBuiltin and IsSubjectToDebugging interchangeably. For debugger, we now use the latter, hiding the detail that only non-builtins are debuggable. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1292283004 Cr-Commit-Position: refs/heads/master@{#30285}
-
mvstanton authored
BUG= Review URL: https://codereview.chromium.org/1292173003 Cr-Commit-Position: refs/heads/master@{#30284}
-
yangguo authored
R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1300333003 Cr-Commit-Position: refs/heads/master@{#30283}
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1303873002 Cr-Commit-Position: refs/heads/master@{#30282}
-
mlippautz authored
GC flags are now part of the {Heap} and should be respected by all sub-components. Also add a infrastructure to write tests accessing private methods. Review URL: https://codereview.chromium.org/1301183002 Cr-Commit-Position: refs/heads/master@{#30281}
-
yangguo authored
We currently have several ways to share symbols that are used in both native scripts and the runtime. This change unifies this. We do not use the symbols registry since we don't need the registry any longer after bootstrapping, but the registry stays alive afterwards. R=mlippautz@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/1293493004 Cr-Commit-Position: refs/heads/master@{#30280}
-
v8-autoroll authored
Rolling v8/tools/clang to 5439585778385813bc7711f3d6b7035b9eb78572 TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/1307783002 Cr-Commit-Position: refs/heads/master@{#30279}
-
- 20 Aug, 2015 16 commits
-
-
yangguo authored
The code should do what the comment says :) R=mstarzinger@chromium.org BUG=chromium:522895 LOG=N Review URL: https://codereview.chromium.org/1300363002 Cr-Commit-Position: refs/heads/master@{#30278}
-
mstarzinger authored
This prevents leakage of the memory-reducer.h declarations inside of the heap and prevents it from being exposed to the world. Protects private state from being inadvertently mocked with. R=mlippautz@chromium.org Review URL: https://codereview.chromium.org/1288913003 Cr-Commit-Position: refs/heads/master@{#30277}
-
mstarzinger authored
This prevents leakage of the gc-tracer.h declarations inside of the heap and prevents it from being exposed to the world. Protects private state from being inadvertently mocked with. R=mlippautz@chromium.org Review URL: https://codereview.chromium.org/1294763004 Cr-Commit-Position: refs/heads/master@{#30276}
-
hpayer authored
Additionally, this CL moves a bit of code around to free up more memory before compaction starts. BUG= Review URL: https://codereview.chromium.org/1305733003 Cr-Commit-Position: refs/heads/master@{#30275}
-
mvstanton authored
The map tells us the source elements kind, and holeyness. BUG= Review URL: https://codereview.chromium.org/1303813004 Cr-Commit-Position: refs/heads/master@{#30274}
-
hpayer authored
Invalid slots in large objects can only occur when large objects became dead. These slots are filtered out already after marking. BUG= Review URL: https://codereview.chromium.org/1298183003 Cr-Commit-Position: refs/heads/master@{#30273}
-
mstarzinger authored
R=hpayer@chromium.org Review URL: https://codereview.chromium.org/1292963006 Cr-Commit-Position: refs/heads/master@{#30272}
-
cbruni authored
Revert of Moving ArraySplice Builtin to ElementsAccessor (patchset #6 id:100001 of https://codereview.chromium.org/1293683005/ ) Reason for revert: failing bot http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/3827 Original issue's description: > - remove the Backing-Store speficic code from builtins.cc and put it in elements.cc. > - adding tests to improve coverage of the splice method > > BUG= > > Committed: https://crrev.com/8533d4b5433d3a9e9fb1015f206997bd6d869fe3 > Cr-Commit-Position: refs/heads/master@{#30269} TBR=mvstanton@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1305763002 Cr-Commit-Position: refs/heads/master@{#30271}
-
mstarzinger authored
This CL us a pure refactoring that makes an empty compilation unit including just "snapshot.h" but not "objects-inl.h" compile without warnings or errors. This is needed to further reduce the header dependency tangle. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1287113010 Cr-Commit-Position: refs/heads/master@{#30270}
-
cbruni authored
- adding tests to improve coverage of the splice method BUG= Review URL: https://codereview.chromium.org/1293683005 Cr-Commit-Position: refs/heads/master@{#30269}
-
mstarzinger authored
This make inclusion of unicode-inl.h in object.h absolete. Now most compilation units don't require that header. It also breaks a cycle within declarations of the scanner.h header. This tries to remove includes of "-inl.h" headers from normal ".h" headers, thereby reducing the chance of any cyclic dependencies and decreasing the average size of our compilation units. Note that this change still leaves 3 violations of that rule in the code, checked with the "tools/check-inline-includes.sh" tool. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1287893006 Cr-Commit-Position: refs/heads/master@{#30268}
-
mlippautz authored
BUG= Review URL: https://codereview.chromium.org/1303443005 Cr-Commit-Position: refs/heads/master@{#30267}
-
yangguo authored
TBR=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1296793003 Cr-Commit-Position: refs/heads/master@{#30266}
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1293593005 Cr-Commit-Position: refs/heads/master@{#30265}
-
yangguo authored
We need this for the debugger and for future changes that need to find all shared function infos (through scripts). R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1297273005 Cr-Commit-Position: refs/heads/master@{#30264}
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1285183010 Cr-Commit-Position: refs/heads/master@{#30263}
-