- 07 Oct, 2015 1 commit
-
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/1393833002 Cr-Commit-Position: refs/heads/master@{#31136}
-
- 06 Oct, 2015 1 commit
-
-
machenbach authored
Revert of [heap] Prepare code for smaller large object allocation limit than max allocatable memory. (patchset #10 id:180001 of https://codereview.chromium.org/1361853005/ ) Reason for revert: [Sheriff] Need to revert for reverting https://codereview.chromium.org/1358703003/ Original issue's description: > [heap] Prepare heap for smaller large object allocation limit than max allocatable memory. > > BUG=chromium:524425 > LOG=n > > Committed: https://crrev.com/c2bce747993c445daf78975392e587bff20c6677 > Cr-Commit-Position: refs/heads/master@{#31107} TBR=mlippautz@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:524425 Review URL: https://codereview.chromium.org/1376413005 Cr-Commit-Position: refs/heads/master@{#31129}
-
- 05 Oct, 2015 1 commit
-
-
hpayer authored
BUG=chromium:524425 LOG=n Review URL: https://codereview.chromium.org/1361853005 Cr-Commit-Position: refs/heads/master@{#31107}
-
- 02 Oct, 2015 3 commits
-
-
danno authored
Previous to this patch, both the lithium and TurboFan register allocators tracked allocated registers by "indices", rather than the register codes used elsewhere in the runtime. This patch ensures that codes are used everywhere, and in the process cleans up a bunch of redundant code and adds more structure to how the set of allocatable registers is defined. Some highlights of changes: * TurboFan's RegisterConfiguration class moved to V8's top level so that it can be shared with Crankshaft. * Various "ToAllocationIndex" and related methods removed. * Code that can be easily shared between Register classes on different platforms is now shared. * The list of allocatable registers on each platform is declared as a list rather than implicitly via the register index <-> code mapping. Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 Cr-Commit-Position: refs/heads/master@{#30913} Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf Cr-Commit-Position: refs/heads/master@{#31075} Review URL: https://codereview.chromium.org/1287383003 Cr-Commit-Position: refs/heads/master@{#31087}
-
danno authored
Revert of Reland: Remove register index/code indirection (patchset #20 id:380001 of https://codereview.chromium.org/1287383003/ ) Reason for revert: Failures on MIPS Original issue's description: > Remove register index/code indirection > > Previous to this patch, both the lithium and TurboFan register > allocators tracked allocated registers by "indices", rather than > the register codes used elsewhere in the runtime. This patch > ensures that codes are used everywhere, and in the process cleans > up a bunch of redundant code and adds more structure to how the > set of allocatable registers is defined. > > Some highlights of changes: > > * TurboFan's RegisterConfiguration class moved to V8's top level > so that it can be shared with Crankshaft. > * Various "ToAllocationIndex" and related methods removed. > * Code that can be easily shared between Register classes on > different platforms is now shared. > * The list of allocatable registers on each platform is declared > as a list rather than implicitly via the register index <-> > code mapping. > > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 > Cr-Commit-Position: refs/heads/master@{#30913} > > Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf > Cr-Commit-Position: refs/heads/master@{#31075} TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1380863004 Cr-Commit-Position: refs/heads/master@{#31083}
-
danno authored
Previous to this patch, both the lithium and TurboFan register allocators tracked allocated registers by "indices", rather than the register codes used elsewhere in the runtime. This patch ensures that codes are used everywhere, and in the process cleans up a bunch of redundant code and adds more structure to how the set of allocatable registers is defined. Some highlights of changes: * TurboFan's RegisterConfiguration class moved to V8's top level so that it can be shared with Crankshaft. * Various "ToAllocationIndex" and related methods removed. * Code that can be easily shared between Register classes on different platforms is now shared. * The list of allocatable registers on each platform is declared as a list rather than implicitly via the register index <-> code mapping. Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 Cr-Commit-Position: refs/heads/master@{#30913} Review URL: https://codereview.chromium.org/1287383003 Cr-Commit-Position: refs/heads/master@{#31075}
-
- 01 Oct, 2015 2 commits
-
-
bmeurer authored
Introduce %_ToNumber intrinsic, which just calls to the existing ToNumberStub, and remove all uses of our custom JavaScript plus intrinsics based ToNumber and friends. Also replace the TO_NUMBER_INLINE macro with TO_NUMBER, which is currently a wrapper for %_ToNumber. Newly written JS code should use TO_NUMBER (similar to TO_STRING, TO_INT32, and friends). Also finally remove the DefaultString/DefaultNumber builtins, which are basically the ES5 version of ToPrimitive. Now all code uses the ES6 version, which is implemented in Object::ToPrimitive and JSReceiver::ToPrimitive in C++. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=jarin@chromium.org BUG=v8:4307 LOG=n Review URL: https://codereview.chromium.org/1384443002 Cr-Commit-Position: refs/heads/master@{#31054}
-
ishell authored
This CL also allows to use arbitrary number of feedback vector elements for particular slot kind. Review URL: https://codereview.chromium.org/1370303004 Cr-Commit-Position: refs/heads/master@{#31050}
-
- 29 Sep, 2015 2 commits
-
-
mvstanton authored
The LiteralsArray will soon hold a type feedback vector. Code treats it as an ordinary fixed array, and needs to stop that. BUG= Review URL: https://codereview.chromium.org/1374723002 Cr-Commit-Position: refs/heads/master@{#31000}
-
bmeurer authored
This adds ES6 compliant Object::ToInteger, Object::ToInt32, Object::ToUint32 and Object::ToLength, and replaces the old Execution wrappers of those abstract operations (which were not using the correct ToPrimitive). This also introduces proper %ToInteger and %ToLength runtime entries, with a fast path %_ToInteger supported in fullcodegen and Crankshaft (for now). Internal JavaScript code should use TO_INTEGER and TO_LENGTH respectively. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg BUG=v8:4307 LOG=n Review URL: https://codereview.chromium.org/1378533002 Cr-Commit-Position: refs/heads/master@{#30993}
-
- 28 Sep, 2015 2 commits
-
-
ishell authored
This is a first step towards merging FeedbackVectorSlot and FeedbackVectorICSlot. Review URL: https://codereview.chromium.org/1369973002 Cr-Commit-Position: refs/heads/master@{#30964}
-
bmeurer authored
Also support %_ToString in Crankshaft utilizing the ToStringStub, which is also used in TurboFan and fullcodegen. This is necessary to repair a regression on Octane that was introduced when switching from the hand crafted NonStringToString/ToString magic to %_ToString (which properly supports @@toPrimitive). BUG=chromium:535953,v8:4307 LOG=n Review URL: https://codereview.chromium.org/1373743002 Cr-Commit-Position: refs/heads/master@{#30955}
-
- 24 Sep, 2015 5 commits
-
-
danno authored
Revert of Remove register index/code indirection (patchset #17 id:320001 of https://codereview.chromium.org/1287383003/ ) Reason for revert: Failures on greedy RegAlloc, Fuzzer Original issue's description: > Remove register index/code indirection > > Previous to this patch, both the lithium and TurboFan register > allocators tracked allocated registers by "indices", rather than > the register codes used elsewhere in the runtime. This patch > ensures that codes are used everywhere, and in the process cleans > up a bunch of redundant code and adds more structure to how the > set of allocatable registers is defined. > > Some highlights of changes: > > * TurboFan's RegisterConfiguration class moved to V8's top level > so that it can be shared with Crankshaft. > * Various "ToAllocationIndex" and related methods removed. > * Code that can be easily shared between Register classes on > different platforms is now shared. > * The list of allocatable registers on each platform is declared > as a list rather than implicitly via the register index <-> > code mapping. > > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 > Cr-Commit-Position: refs/heads/master@{#30913} TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1365073002 Cr-Commit-Position: refs/heads/master@{#30914}
-
danno authored
Previous to this patch, both the lithium and TurboFan register allocators tracked allocated registers by "indices", rather than the register codes used elsewhere in the runtime. This patch ensures that codes are used everywhere, and in the process cleans up a bunch of redundant code and adds more structure to how the set of allocatable registers is defined. Some highlights of changes: * TurboFan's RegisterConfiguration class moved to V8's top level so that it can be shared with Crankshaft. * Various "ToAllocationIndex" and related methods removed. * Code that can be easily shared between Register classes on different platforms is now shared. * The list of allocatable registers on each platform is declared as a list rather than implicitly via the register index <-> code mapping. Review URL: https://codereview.chromium.org/1287383003 Cr-Commit-Position: refs/heads/master@{#30913}
-
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 1 commit
-
-
jkummerow authored
BUG=chromium:527994 LOG=n Review URL: https://codereview.chromium.org/1358393004 Cr-Commit-Position: refs/heads/master@{#30889}
-
- 22 Sep, 2015 3 commits
-
-
bmeurer authored
Slow path for relational comparison of boolean primitive values now goes through the runtime, which made the slow path even slower than it already was. So in order to repair the regression, we just track boolean feedback for comparisons and use that to generate decent code in Crankshaft (not the best possible code, but good enough for Crankshaft; TurboFan will be able to do better on that). R=jarin@chromium.org BUG=chromium:534200 LOG=n Review URL: https://codereview.chromium.org/1347063004 Cr-Commit-Position: refs/heads/master@{#30860}
-
bmeurer authored
Now the StringAddStub can optionally convert it's parameters to strings (following the rules for the addition operator). This could be further optimized once we have a ToPrimitiveStub, but it should be sufficient for the moment. Also removed the unused Strength parameter to the HStringAdd operator, because string addition does not depend on language mode. R=jarin@chromium.org BUG=v8:4307, chromium:532524 LOG=n Committed: https://crrev.com/d261849e53fbf8c36efae42d478271f87acff70f Cr-Commit-Position: refs/heads/master@{#30726} Review URL: https://codereview.chromium.org/1339053002 Cr-Commit-Position: refs/heads/master@{#30858}
-
bmeurer authored
If @@toStringTag is an accessor property, we cannot assume that the result of calling Object.prototype.toString() for objects with the same map. R=adamk@chromium.org BUG=chromium:534200 LOG=n Review URL: https://codereview.chromium.org/1360723002 Cr-Commit-Position: refs/heads/master@{#30856}
-
- 21 Sep, 2015 3 commits
-
-
bmeurer authored
Previously we only collected the known map for equality comparisons. But if we also collect it for relational comparisons, we can inline a fast path of ToPrimitive on the objects, which is especially interesting since both sides have the same map. For now we only inline a very limited subset of ToPrimitive in Crankshaft, which is when the receiver map (and its prototype chain) doesn't have @@toPrimitive, and both valueOf and toString are the default versions on the %ObjectPrototype%. In this case the relational comparison would reduce to a string comparison of "[object CLASS]" with itself and so we can reduce that to a boolean constant plus map checks on both left and right hand side, plus code dependencies on the prototype chain. This repairs the regression on box2d. R=jkummerow@chromium.org BUG=chromium:534200 LOG=n Review URL: https://codereview.chromium.org/1355113002 Cr-Commit-Position: refs/heads/master@{#30852}
-
bmeurer authored
This doesn't fix the performance regression mentioned by the bug yet, but is necessary cleanup to land the fix, and should be separated from the actual fix. R=jkummerow@chromium.org BUG=chromium:534200 LOG=n Review URL: https://codereview.chromium.org/1345313005 Cr-Commit-Position: refs/heads/master@{#30847}
-
littledan authored
ES2015 specifies very particular semantics for functions defined in blocks. In strict mode, it is simply a lexical binding scoped to that block. In sloppy mode, in addition to that lexical binding, there is a var-style binding in the outer scope, which is overwritten with the local binding when the function declaration is evaluated, *as long as* introducing ths var binding would not create a var/let conflict in the outer scope. This patch implements the semantics by introducing a DelegateStatement, which is initially filled in with the EmptyStatement and overwritten with the assignment when the scope is closed out and it can be checked that there is no conflict. This patch is tested with a new mjsunit test, and I tried staging it and running test262, finding that the tests that we have disabled due to lack of Annex B support now pass. R=adamk,rossberg LOG=Y BUG=v8:4285 Review URL: https://codereview.chromium.org/1332873003 Cr-Commit-Position: refs/heads/master@{#30842}
-
- 18 Sep, 2015 3 commits
-
-
cbruni authored
BUG= Review URL: https://codereview.chromium.org/1350293002 Cr-Commit-Position: refs/heads/master@{#30823}
-
jkummerow authored
This extends instrumentation added in r30683 and r30768 to cover the possibility that the root cause we're after is in optimized code. This CL is intended to be reverted in a couple of days, but should cause no harm while it's in the tree (we would crash anyway). BUG=chromium:527994 LOG=n Review URL: https://codereview.chromium.org/1348823003 Cr-Commit-Position: refs/heads/master@{#30819}
-
bmeurer authored
This removes the weird COMPARE and COMPARE_STRONG JavaScript builtins and replaces them with a proper C++ implementation in Object::Compare and appropriate wrappers Object::LessThan, Object::GreaterThan, and friends that are intended to be used by a true/false returning CompareIC in the future, as well as the interpreter. As a short-term solution we provide %Compare and %Compare_Strong entry points for the current CompareIC that return the appropriate integer values expected by fullcodegen currently. Now the Abstract Relational Comparison is also using the correct ToPrimitive implementation, which properly supports @@toPrimitive. BUG=v8:4307 LOG=n Review URL: https://codereview.chromium.org/1350113002 Cr-Commit-Position: refs/heads/master@{#30816}
-
- 16 Sep, 2015 1 commit
-
-
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}
-
- 15 Sep, 2015 2 commits
-
-
machenbach authored
Revert of [crankshaft] Re-add fast-case for string add left/right. (patchset #1 id:1 of https://codereview.chromium.org/1339053002/ ) Reason for revert: [Sheriff] Fails mozilla with deadcode: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20deadcode/builds/5357 Original issue's description: > [crankshaft] Re-add fast-case for string add left/right. > > Now the StringAddStub can optionally convert it's parameters to strings > (following the rules for the addition operator). This could be further > optimized once we have a ToPrimitiveStub, but it should be sufficient > for the moment. > > Also removed the unused Strength parameter to the HStringAdd operator, > because string addition does not depend on language mode. > > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_win_nosnap_shared_rel,v8_linux_nosnap_dbg > R=mstarzinger@chromium.org > BUG=v8:4307 > LOG=n > > Committed: https://crrev.com/d261849e53fbf8c36efae42d478271f87acff70f > Cr-Commit-Position: refs/heads/master@{#30726} TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4307 Review URL: https://codereview.chromium.org/1347473003 Cr-Commit-Position: refs/heads/master@{#30727}
-
bmeurer authored
Now the StringAddStub can optionally convert it's parameters to strings (following the rules for the addition operator). This could be further optimized once we have a ToPrimitiveStub, but it should be sufficient for the moment. Also removed the unused Strength parameter to the HStringAdd operator, because string addition does not depend on language mode. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_win_nosnap_shared_rel,v8_linux_nosnap_dbg R=mstarzinger@chromium.org BUG=v8:4307 LOG=n Review URL: https://codereview.chromium.org/1339053002 Cr-Commit-Position: refs/heads/master@{#30726}
-
- 14 Sep, 2015 1 commit
-
-
bmeurer authored
These builtins present an optimization for the general addition case, where one side is already known to be a string. Unfortunately this optimization is wrong in the presence of @@toPrimitive (there are some ideas how to implement a similar optimization using the prototype backpointer mechanism that jkummerow@ introduced earlier). So this also removes the broken %_IsStringWrapperSafeForDefaultValueOf, which is the key part of the optimization mentioned above. R=mstarzinger@chromium.org BUG=v8:4307 LOG=n Review URL: https://codereview.chromium.org/1336273002 Cr-Commit-Position: refs/heads/master@{#30707}
-
- 10 Sep, 2015 5 commits
-
-
mvstanton authored
The refactoring is because it's awkward and error-prone to deterimine which IC slot an ObjectLiteralProperty uses for feedback. The fix is for each one to know it's own slot. In the numbering pass, we allocate slots for the ObjectLiteral, then hand out those slots into the properties. It adds one word to the ObjectLiteralProperty expression - I'm investigating if thats a problem. This changes makes compiling the object literal cleaner across the three compilers. Also, the slot allocation logic in ObjectLiteral::ComputeFeedbackRequirements() was refactoring to mimic the style in full-codegen. This is useful since it must remain in sync with FullCodegen::VisitObjectLiteral(). Review URL: https://codereview.chromium.org/1321993004 Cr-Commit-Position: refs/heads/master@{#30686}
-
bmeurer authored
Replace the ADD, SUB, etc. builtins with proper runtime implementations, and expose them as runtime calls that can be used by the code stubs and the interpreter (for now). Also remove all the support runtime functions for ADD, SUB and friends, namely %NumberAdd, %NumberSub, and so on. R=mstarzinger@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg Review URL: https://codereview.chromium.org/1333843002 Cr-Commit-Position: refs/heads/master@{#30680}
-
mvstanton authored
Narrowed the scope of the fix, to make a best effort to avoid DEOPT in case the hole is loaded, but not to permute the choice of a consolidated load in case that effort fails. BUG=chromium:530005 LOG=N Review URL: https://codereview.chromium.org/1330233004 Cr-Commit-Position: refs/heads/master@{#30677}
-
cbruni authored
BUG= Review URL: https://codereview.chromium.org/1330153003 Cr-Commit-Position: refs/heads/master@{#30676}
-
bmeurer authored
There are now two runtime entries %NewClosure and %NewClosure_Tenured, with the same signature (one parameter, the SharedFunctionInfo, and the context of the caller). Also remove the HFunctionLiteral special case instruction from Crankshaft, as HCallWithDescriptor with FastNewClosureStub or HCallRuntime with either %NewClosure or %NewClosure_Tenured can easily do that for you. Also remove the redundant context parameter from the JSCreateClosure operator, because every JS operator already takes a context input. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg Review URL: https://codereview.chromium.org/1329293003 Cr-Commit-Position: refs/heads/master@{#30671}
-
- 09 Sep, 2015 2 commits
-
-
mvstanton authored
Update the consolidated load case to carefully chose the load mode based on the consolidated elements kind. BUG=v8:4380 LOG=N Review URL: https://codereview.chromium.org/1329793003 Cr-Commit-Position: refs/heads/master@{#30659}
-
bmeurer authored
The number of actual arguments should always be available, there's no point in trying to optimize away a simple assignment of an immediate to a register before some calls. The main motivation is to have a consistent state at the beginning of every function. Currently the arguments register (i.e. rax or eax) either contains the number of arguments or some random garbage depending on whether the callsite decided that the callee might need the information or not. This causes trouble with runtime implementations of functions that do not set internal_formal_parameter_count to the DontAdaptArguments sentinel (we don't have any of those yet), but also makes it impossible to sanity check the arguments in the callee, because the callee doesn't know whether the caller decided to pass the number of arguments or random garbage. BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1330033002 Cr-Commit-Position: refs/heads/master@{#30648}
-
- 08 Sep, 2015 1 commit
-
-
bmeurer authored
The semantics of the %_CallFunction intrinsic seem to be very unclear, which resulted in a lot of bugs. Especially the combination with %IsSloppyModeFunction is always a bug, because the receiver would be wrapped in the wrong context. So the %IsSloppyModeFunction helper is gone now, and many of the buggy uses of %_CallFunction are also eliminated. If you ever need to call something with a different receiver, then %_Call is your friend now. It does what you want and implements the call sequence fully (and correct). BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1325573004 Cr-Commit-Position: refs/heads/master@{#30634}
-
- 04 Sep, 2015 1 commit
-
-
bmeurer authored
Similar to DELETE, the IN builtin is just a thin wrapper for %HasElement and %HasProperty anyway, and cannot be optimized, plus it had a weird special fast case (which also involved at least one LOAD_IC plus some intrinsic magic). R=yangguo@chromium.org,jarin@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_win_nosnap_shared_rel Committed: https://crrev.com/72d60a1e80e81e2e68ca402665e2acbc46c5e471 Cr-Commit-Position: refs/heads/master@{#30154} Review URL: https://codereview.chromium.org/1295433002 Cr-Commit-Position: refs/heads/master@{#30582}
-