- 22 Oct, 2015 1 commit
-
-
rmcilroy authored
Fills out some more of the function prologue support in the interpreter. Deals with creation of arguments objects and throwing IllegalRedeclarations if necessary. Also adds (untested) support for this.function and new.target variable assignment. Also fixes a bug in Frames::is_java_script() to deal with interpreter frames correctly. Cleans up comments in builtins InterpreterEntryTrampoline about missing prologue support. Adds the following bytecodes: - CreateArgumentsSloppy - CreateArgumentsStrict BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1412953007 Cr-Commit-Position: refs/heads/master@{#31486}
-
- 15 Oct, 2015 3 commits
-
-
oth authored
This change add a new bytecode for operator new and implements it using the Construct() builtin. BUG=v8:4280 LOG=N Committed: https://crrev.com/8e4f9963d53913eab7fbd2f61a5733d8dc2169e7 Cr-Commit-Position: refs/heads/master@{#31293} Review URL: https://codereview.chromium.org/1402943002 Cr-Commit-Position: refs/heads/master@{#31312}
-
machenbach authored
Revert of [Interpreter] Support for operator new. (patchset #17 id:290001 of https://codereview.chromium.org/1402943002/ ) Reason for revert: [Sheriff] Breaks arm64 debug: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/4595 Original issue's description: > [Interpreter] Support for operator new. > > This change add a new bytecode for operator new and implements it using > the Construct() builtin. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/8e4f9963d53913eab7fbd2f61a5733d8dc2169e7 > Cr-Commit-Position: refs/heads/master@{#31293} TBR=rmcilroy@chromium.org,bmeurer@chromium.org,oth@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review URL: https://codereview.chromium.org/1402153004 Cr-Commit-Position: refs/heads/master@{#31298}
-
oth authored
This change add a new bytecode for operator new and implements it using the Construct() builtin. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1402943002 Cr-Commit-Position: refs/heads/master@{#31293}
-
- 06 Oct, 2015 1 commit
-
-
bmeurer authored
When calling into C++ builtins, we need to make sure that the argument count register contains the correct number of arguments, otherwise the CEntryStub will not be able to leave the stack in the correct state. R=ishell@chromium.org BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1391543002 Cr-Commit-Position: refs/heads/master@{#31120}
-
- 02 Oct, 2015 5 commits
-
-
rmcilroy authored
Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31089}
-
rmcilroy authored
Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #8 id:220001 of https://codereview.chromium.org/1362383002/ ) Reason for revert: Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot) Original issue's description: > [Interpreter] Add CallRuntime support to the interpreter. > > Adds support for calling runtime functions from the interpreter. Adds the > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call > and the arguments in sequential registers. Adds a InterpreterCEntry builtin > to enable the interpreter to enter C++ code based on the functionId. > > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall > and groups all the interpreter builtins together. > > BUG=v8:4280 > LOG=N > TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review URL: https://codereview.chromium.org/1379933003 Cr-Commit-Position: refs/heads/master@{#31078}
-
rmcilroy authored
Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc Cr-Commit-Position: refs/heads/master@{#31064} Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31076}
-
rmcilroy authored
Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #6 id:180001 of https://codereview.chromium.org/1362383002/ ) Reason for revert: Broke Arm64 bot (CEntry stub is trying to pop arguments off stack when argv_in_reg, so I need to fix this). Original issue's description: > [Interpreter] Add CallRuntime support to the interpreter. > > Adds support for calling runtime functions from the interpreter. Adds the > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call > and the arguments in sequential registers. Adds a InterpreterCEntry builtin > to enable the interpreter to enter C++ code based on the functionId. > > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall > and groups all the interpreter builtins together. > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc > Cr-Commit-Position: refs/heads/master@{#31064} TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review URL: https://codereview.chromium.org/1387543002 Cr-Commit-Position: refs/heads/master@{#31066}
-
rmcilroy authored
Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31064}
-
- 24 Sep, 2015 3 commits
-
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4413, v8:4430 LOG=n Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 Cr-Commit-Position: refs/heads/master@{#30900} Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30902}
-
bmeurer authored
Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ ) Reason for revert: Failed on Fuzzer and MIPS bot. Original issue's description: > [es6] Introduce spec compliant IsConstructor. > > There was already a bit on the Map named "function with prototype", > which basically meant that the Map was a map for a JSFunction that could > be used as a constructor. Now this CL generalizes that bit to > IsConstructor, which says that whatever (Heap)Object you are looking at > can be used as a constructor (i.e. the bit is also set for bound > functions that can be used as constructors and proxies that have a > [[Construct]] internal method). > > This way we have a single chokepoint for IsConstructor checking, which > allows us to get rid of the various ways in which we tried to guess > whether something could be used as a constructor or not. > > Drive-by-fix: Renamed IsConstructor on FunctionKind to > IsClassConstructor to resolve the weird name clash, and the > IsClassConstructor name also matches the spec. > > R=jarin@chromium.org, rossberg@chromium.org > BUG=v8:4430 > LOG=n > > Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 > Cr-Commit-Position: refs/heads/master@{#30900} TBR=jarin@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4430 Review URL: https://codereview.chromium.org/1360403002 Cr-Commit-Position: refs/heads/master@{#30901}
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4430 LOG=n Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30900}
-
- 23 Sep, 2015 2 commits
-
-
bmeurer authored
We somehow try to push some stuff on the stack when we detect a stack overflow, that we don't need. Even worse we might access outside the valid stack bounds. Since we don't need this, it's gone. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=jarin@chromium.org BUG=chromium:534881 LOG=n Review URL: https://codereview.chromium.org/1360953003 Cr-Commit-Position: refs/heads/master@{#30883}
-
bmeurer authored
Now both Execution::Call and Execution::New can deal with any kind of target and will raise a proper exception if the target is not callable (which is not yet spec compliant for New, as we would have to check IsConstructor instead, which we don't have yet). Now we no longer need to do any of these weird call/construct delegate gymnastics in C++, and we finally have a single true bottleneck for Call/Construct abstract operations in the code base, with only a few special handlings left in the compilers to optimize the JSFunction case. R=jarin@chromium.org BUG=v8:4430, v8:4413 LOG=n Review URL: https://codereview.chromium.org/1360793002 Cr-Commit-Position: refs/heads/master@{#30874}
-
- 22 Sep, 2015 1 commit
-
-
bmeurer authored
Introduce new builtins Construct and ConstructFunction (in line with the Call and CallFunction builtins that we already have) as proper bottleneck for Construct and [[Construct]] on JSFunctions. Use these builtins to support passing NewTarget from C++ to JavaScript land. Long-term we want the CallConstructStub to be used for gathering feedback on entry to construction chain (i.e. the initial new Foo), and use the Construct builtins to do the actual work inside the construction chain (i.e. calling into super and stuff). MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com. R=jarin@chromium.org BUG=v8:4430 LOG=n Review URL: https://codereview.chromium.org/1359583002 Cr-Commit-Position: refs/heads/master@{#30857}
-
- 17 Sep, 2015 3 commits
-
-
bmeurer authored
Currently Execution::Call (and friends) still duplicate a lot of the Call sequence logic that should be encapsulated in the Call and CallFunction builtins. So the plan now is to switch Execution::Call to accept any Callable and just pass that through to the Call builtin. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg R=jarin@chromium.org BUG=v8:4413 LOG=n Committed: https://crrev.com/359645f48156e15f235e9a9ede7910e0bcd9ae45 Cr-Commit-Position: refs/heads/master@{#30791} Review URL: https://codereview.chromium.org/1353723002 Cr-Commit-Position: refs/heads/master@{#30808}
-
machenbach authored
Revert of [runtime] Initial step towards switching Execution::Call to callable. (patchset #1 id:1 of https://codereview.chromium.org/1353723002/ ) Reason for revert: [Sheriff] Causes a dcheck failure in layout tests (and some test changes in release): https://storage.googleapis.com/chromium-layout-test-archives/V8-Blink_Linux_64__dbg_/1442/layout-test-results/virtual/android/fullscreen/api/element-request-fullscreen-top-stderr.txt from http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/1442 Original issue's description: > [runtime] Initial step towards switching Execution::Call to callable. > > Currently Execution::Call (and friends) still duplicate a lot of the > Call sequence logic that should be encapsulated in the Call and > CallFunction builtins. So the plan now is to switch Execution::Call > to accept any Callable and just pass that through to the Call builtin. > > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg > R=jarin@chromium.org > BUG=v8:4413 > LOG=n > > Committed: https://crrev.com/359645f48156e15f235e9a9ede7910e0bcd9ae45 > Cr-Commit-Position: refs/heads/master@{#30791} TBR=jarin@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4413 Review URL: https://codereview.chromium.org/1346763005 Cr-Commit-Position: refs/heads/master@{#30793}
-
bmeurer authored
Currently Execution::Call (and friends) still duplicate a lot of the Call sequence logic that should be encapsulated in the Call and CallFunction builtins. So the plan now is to switch Execution::Call to accept any Callable and just pass that through to the Call builtin. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg R=jarin@chromium.org BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1353723002 Cr-Commit-Position: refs/heads/master@{#30791}
-
- 16 Sep, 2015 3 commits
-
-
mvstanton authored
There isn't a plan to turn it on soon, so we'll take it out in favor of cleaner code. BUG= Review URL: https://codereview.chromium.org/1202173002 Cr-Commit-Position: refs/heads/master@{#30767}
-
bmeurer authored
Implement the String constructor completely as native builtin, avoiding the need to do gymnastics in JavaScript builtin to properly detect the no argument case (which is different from the undefined argument case) and also allowing to just tailcall through to ToString or SymbolDescriptiveString for the common case. Also the JavaScript builtin was misleading since the case for construct call was unused, but could be triggered in a wrong way once we support tail calls from constructor functions. This refactoring allows us to properly implement subclassing for String builtins, once we have the correct initial_map on derived classes (it's merely a matter of using NewTarget instead of the target register now). This introduces a new %SymbolDescriptiveString runtime entry, which is also used by Symbol.toString() now. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1344893002 Cr-Commit-Position: refs/heads/master@{#30759}
-
mvstanton authored
BUG=v8:4423 LOG=N Review URL: https://codereview.chromium.org/1342013003 Cr-Commit-Position: refs/heads/master@{#30758}
-
- 14 Sep, 2015 2 commits
-
-
rmcilroy authored
Adds support for JS calls to the interpreter. In order to support calls from the interpreter, the PushArgsAndCall builtin is added which pushes a sequence of arguments onto the stack and calls builtin::Call. Adds the Call bytecode. MIPS port contributed by akos.palfi@imgtec.com in https://codereview.chromium.org/1334873002/ BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1323463005 Cr-Commit-Position: refs/heads/master@{#30710}
-
bmeurer authored
The String constructor was somewhat complex with a lot of micro optimizations that are not relevant or even misguided. It would be really hard to port that code to ES6, which requires String to be subclassable. So as a first step we reduced the necessary complexity to the bare minimum (also removing the last user of the fairly complex MacroAssembler::LookupNumberStringCache method). This also removes the counters for the String constructor, which were not properly exposed anymore (and not kept in sync with inlined versions of the String constructor anyway). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1335193002 Cr-Commit-Position: refs/heads/master@{#30706}
-
- 11 Sep, 2015 1 commit
-
-
bmeurer authored
Just use a %ThrowStackOverflow runtime function instead, which does the trick, especially since the Isolate already has a preallocated StackOverflow error for that. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1337883002 Cr-Commit-Position: refs/heads/master@{#30693}
-
- 08 Sep, 2015 3 commits
-
-
bmeurer authored
The new Call and CallFunction builtins supersede the current CallFunctionStub (and CallIC magic) and will be the single bottleneck for all calling, including the currently special Function.prototype.call and Function.prototype.apply builtins, which had handwritten (and not fully compliant) versions of CallFunctionStub, and also the CallIC(s), which where also slightly different. This also reduces the overhead for API function calls, which is still unnecessary high, but let's do that step-by-step. This also fixes a bunch of cases where the implicit ToObject for sloppy receivers was done in the wrong context (in the caller context instead of the callee context), which basically meant that we allowed cross context access to %ObjectPrototype%. MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com. R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg BUG=v8:4413 LOG=n Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277 Cr-Commit-Position: refs/heads/master@{#30627} Review URL: https://codereview.chromium.org/1311013008 Cr-Commit-Position: refs/heads/master@{#30629}
-
bmeurer authored
Revert of [builtins] Unify the various versions of [[Call]] with a Call builtin. (patchset #10 id:260001 of https://codereview.chromium.org/1311013008/ ) Reason for revert: Breaks nosnap, needs investigation Original issue's description: > [builtins] Unify the various versions of [[Call]] with a Call builtin. > > The new Call and CallFunction builtins supersede the current > CallFunctionStub (and CallIC magic) and will be the single bottleneck > for all calling, including the currently special Function.prototype.call > and Function.prototype.apply builtins, which had handwritten (and > not fully compliant) versions of CallFunctionStub, and also the > CallIC(s), which where also slightly different. > > This also reduces the overhead for API function calls, which is still > unnecessary high, but let's do that step-by-step. > > This also fixes a bunch of cases where the implicit ToObject for > sloppy receivers was done in the wrong context (in the caller > context instead of the callee context), which basically meant > that we allowed cross context access to %ObjectPrototype%. > > MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com. > > R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg > BUG=v8:4413 > LOG=n > > Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277 > Cr-Commit-Position: refs/heads/master@{#30627} TBR=rmcilroy@chromium.org,jarin@chromium.org,mstarzinger@chromium.org,mvstanton@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4413 Review URL: https://codereview.chromium.org/1328963004 Cr-Commit-Position: refs/heads/master@{#30628}
-
bmeurer authored
The new Call and CallFunction builtins supersede the current CallFunctionStub (and CallIC magic) and will be the single bottleneck for all calling, including the currently special Function.prototype.call and Function.prototype.apply builtins, which had handwritten (and not fully compliant) versions of CallFunctionStub, and also the CallIC(s), which where also slightly different. This also reduces the overhead for API function calls, which is still unnecessary high, but let's do that step-by-step. This also fixes a bunch of cases where the implicit ToObject for sloppy receivers was done in the wrong context (in the caller context instead of the callee context), which basically meant that we allowed cross context access to %ObjectPrototype%. MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com. R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1311013008 Cr-Commit-Position: refs/heads/master@{#30627}
-
- 31 Aug, 2015 1 commit
-
-
bmeurer authored
The call protocol requires that the register dedicated to the number of actual arguments (i.e. rax on x64) always contains the actual arguments. That means after adapting arguments it should match the number of expected arguments. But currently we pass some semi-random value (usually some stack address) after adapting arguments. It looks like this is currently not observable anywhere, because our builtins and functions either don't look at the number of arguments and just make hard coded (unchecked) assumptions, or are marked as "don't adapt arguments", which bypasses the broken code in the trampoline for arguments adaption. Nevertheless this should be fixed. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1306423003 Cr-Commit-Position: refs/heads/master@{#30467}
-
- 28 Aug, 2015 1 commit
-
-
bmeurer authored
This adds a new ToString runtime function and a fast-path ToStringStub (which is just a simple dispatcher for existing functionality), and also implements %_ToName using the ToStringStub. R=mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:4307 LOG=n Review URL: https://codereview.chromium.org/1319973007 Cr-Commit-Position: refs/heads/master@{#30442}
-
- 27 Aug, 2015 2 commits
-
-
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}
-
- 18 Aug, 2015 1 commit
-
-
rmcilroy authored
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=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1289863003 Cr-Commit-Position: refs/heads/master@{#30219}
-
- 17 Aug, 2015 1 commit
-
-
mstarzinger authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1299563003 Cr-Commit-Position: refs/heads/master@{#30187}
-
- 11 Aug, 2015 1 commit
-
-
bmeurer authored
This way we can greatly simplify the different variants of ToObject in our codebase and make them more uniform and robust. Adding a new primitive doesn't require finding and changing all those places again, but it is sufficient to setup the constructor function index when allocating the map. We use the inobject properties field of Map, which is invalid primitive maps anyway. R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1276533003 Cr-Commit-Position: refs/heads/master@{#30119}
-
- 31 Jul, 2015 2 commits
-
-
mvstanton authored
Since we need the notion of a dummy vector ic, we can use that to avoid a special case of the IC constructor. Also, consolidate the two dummy ICs into one. BUG= Review URL: https://codereview.chromium.org/1268783004 Cr-Commit-Position: refs/heads/master@{#29956}
-
bmeurer authored
This is the initial (big) step towards a more uniform implementation of the ToObject abstract operation (ES6 7.1.13), where we have a fallback implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub to deal with the fast case (we should be able to do more cleanup on this in a followup CL). For natives we expose the abstract operation via a %_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT, $toObject and %$toObject. Now the whole implementation of the abstract operation is context independent, meaning we don't need any magic in the builtins object nor the native context. R=mvstanton@chromium.org,yangguo@chromium.org Review URL: https://codereview.chromium.org/1266013006 Cr-Commit-Position: refs/heads/master@{#29953}
-
- 30 Jul, 2015 1 commit
-
-
rmcilroy authored
Adds interpreter entry and exit trampoline builtins. Also implements the Return bytecode handler and fixes a few bugs in InterpreterAssembler highlighted by running on other architectures. MIPS and MIPS64 port contributed by Paul Lind (paul.lind@imgtec.com) BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1245133002 Cr-Commit-Position: refs/heads/master@{#29929}
-
- 24 Jul, 2015 1 commit
-
-
yangguo authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1248443003 Cr-Commit-Position: refs/heads/master@{#29840}
-
- 17 Jul, 2015 1 commit
-
-
mlippautz authored
Additionally, push the allocation site or undefined independently of creating a memento to preserve a fixed size for the construct frames. BUG= Review URL: https://codereview.chromium.org/1239593003 Cr-Commit-Position: refs/heads/master@{#29719}
-