- 03 Mar, 2016 1 commit
-
-
bmeurer authored
This is more consistent with the current naming scheme (i.e. IsCallable for callable bit on map, IsConstructor for constructor bit on map, and now IsUndetectable for undetectable bit on map). Also simplify the fallthrough case for Object::Equals, because we don't need to check for Null or Undefined or Undetectable, as both Null and Undefined already have the undetectable bit set on their maps. R=machenbach@chromium.org Review URL: https://codereview.chromium.org/1756413003 Cr-Commit-Position: refs/heads/master@{#34458}
-
- 26 Feb, 2016 1 commit
-
-
bmeurer authored
The treatment of different undetectable objects was inconsistent after the latest changes to the undetectable bit in the maps. Given two different undetectable JSObjects a and b, a monomorphic CompareIC would say false for a == b, while the rest of the system (including the generic case for the CompareIC) would say true. The fix is rather straight-forward: We just go generic on a CompareIC once we see an undetectable JSObject. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1735863004 Cr-Commit-Position: refs/heads/master@{#34315}
-
- 16 Feb, 2016 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1693833002 Cr-Commit-Position: refs/heads/master@{#34036}
-
- 02 Feb, 2016 1 commit
-
-
jarin authored
This CL removes the Config templatization from the types. It is not necessary anymore, after the HeapTypes have been removed. The CL also changes the type hierarchy - the specific type kinds are not inner classes of the Type class and they do not inherit from Type. This is partly because it seems impossible to make this work without templates. Instead, a new TypeBase class is introduced and all the structural (i.e., non-bitset) types inherit from it. The bitset type still requires the bit-munging hack and some nasty reinterpret-casts to pretend bitsets are of type Type*. Additionally, there is now the same hack for TypeBase - all pointers to the sub-types of TypeBase are reinterpret-casted to Type*. This is to keep the type constructors in inline method definitions (although it is unclear how much that actually buys us). In future, we would like to move to a model where we encapsulate Type* into a class (or possibly use Type where we used to use Type*). This would loosen the coupling between bitset size and pointer size, and eventually we would be able to have more bits. TBR=bradnelson@chromium.org Review URL: https://codereview.chromium.org/1655833002 Cr-Commit-Position: refs/heads/master@{#33656}
-
- 07 Dec, 2015 1 commit
-
-
bmeurer authored
There's no reason to limit the CompareIC to (known) JSObject instances, as all JSReceivers behave the same wrt. abstract and strict equality. So remove this historical limitation and track JSReceivers instead. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1502963002 Cr-Commit-Position: refs/heads/master@{#32642}
-
- 01 Dec, 2015 1 commit
-
-
bmeurer authored
This is the initial support for binary operation hints on javascript binary operators, i.e. JSAdd, JSSubtract and so on. The hints are extracted from the fullcodegen code object before graph building and the AstGraphBuilder puts those hints on the operators if available. R=jarin@chromium.org BUG=v8:4583 LOG=n Review URL: https://codereview.chromium.org/1487973002 Cr-Commit-Position: refs/heads/master@{#32443}
-
- 09 Nov, 2015 1 commit
-
-
bmeurer authored
Introduce receiver conversion mode specialization for the Call and CallFunction builtins, so we can specialize the builtin functionality (actually an optimization only) based on static information from the callsite (this is basically a superset of the optimizations that were available with the CallFunctionStub and CallICStub, except that these optimizations are correct now). This fixes a regression introduced by the removal of CallFunctionStub, for programs that call a lot. R=yangguo@chromium.org BUG=chromium:552244 LOG=n Review URL: https://codereview.chromium.org/1436493002 Cr-Commit-Position: refs/heads/master@{#31871}
-
- 05 Nov, 2015 1 commit
-
-
verwaest authored
This fixes receiver conversion since the Call builtin does it correctly. BUG=v8:4526 LOG=n Review URL: https://codereview.chromium.org/1407373007 Cr-Commit-Position: refs/heads/master@{#31823}
-
- 22 Sep, 2015 1 commit
-
-
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}
-
- 21 Sep, 2015 1 commit
-
-
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}
-
- 14 Aug, 2015 1 commit
-
-
mstarzinger authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1293793002 Cr-Commit-Position: refs/heads/master@{#30178}
-
- 30 Jun, 2015 1 commit
-
-
conradw authored
Also fixes a crankshaft bug with strong implicit conversions. It turns out that the implicit conversion of oddball values is smushed into so many places in crankshaft that it would have been pretty invasive surgery to make everything fall out naturally. BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1216463003 Cr-Commit-Position: refs/heads/master@{#29381}
-
- 08 Jun, 2015 1 commit
-
-
conradw authored
Boolean "is_strong" parameters have begun to proliferate across areas where strong mode semantics are different. This CL repurposes the existing ObjectStrength enum as a replacement for them. BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1144183004 Cr-Commit-Position: refs/heads/master@{#28839}
-
- 04 Jun, 2015 1 commit
-
-
mbrandy authored
Embed constant pools within their corresponding Code objects. This removes support for out-of-line constant pools in favor of the new approach -- the main advantage being that it eliminates the need to allocate and manage separate constant pool array objects. Currently supported on PPC and ARM. Enabled by default on PPC only. This yields a 6% improvment in Octane on PPC64. R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com BUG=chromium:478811 LOG=Y Review URL: https://codereview.chromium.org/1162993006 Cr-Commit-Position: refs/heads/master@{#28801}
-
- 03 Jun, 2015 1 commit
-
-
bmeurer authored
Revert of Embedded constant pools. (patchset #12 id:220001 of https://codereview.chromium.org/1131783003/) Reason for revert: Breaks Linux nosnap cctest/test-api/FastReturnValuesWithProfiler, see http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%202/builds/609/steps/Check/logs/FastReturnValuesWithP.. Original issue's description: > Add support for Embedded Constant Pools for PPC and Arm > > Embed constant pools within their corresponding Code > objects. > > This removes support for out-of-line constant pools in favor > of the new approach -- the main advantage being that it > eliminates the need to allocate and manage separate constant > pool array objects. > > Currently supported on PPC and ARM. Enabled by default on > PPC only. > > This yields a 6% improvment in Octane on PPC64. > > R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com > BUG=chromium:478811 > LOG=Y > > Committed: https://crrev.com/a9404029343d65f146e3443f5280c40a97e736af > Cr-Commit-Position: refs/heads/master@{#28770} TBR=rmcilroy@chromium.org,ishell@chromium.org,rodolph.perfetta@arm.com,mbrandy@us.ibm.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:478811 Review URL: https://codereview.chromium.org/1155703006 Cr-Commit-Position: refs/heads/master@{#28772}
-
- 02 Jun, 2015 1 commit
-
-
mbrandy authored
Embed constant pools within their corresponding Code objects. This removes support for out-of-line constant pools in favor of the new approach -- the main advantage being that it eliminates the need to allocate and manage separate constant pool array objects. Currently supported on PPC and ARM. Enabled by default on PPC only. This yields a 6% improvment in Octane on PPC64. R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:478811 LOG=Y Review URL: https://codereview.chromium.org/1131783003 Cr-Commit-Position: refs/heads/master@{#28770}
-
- 01 Jun, 2015 1 commit
-
-
erikcorry authored
When compiling on a laptop I like to concatenate the small test files. This makes a big difference to compile times. These changes make that easier. R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/1163803002 Cr-Commit-Position: refs/heads/master@{#28742}
-
- 24 Apr, 2015 1 commit
-
-
conradw authored
Implements the strong mode proposal's restrictions on implicit conversions for binary arithmetic operations, not including the + special case. Adds some infrastructure for future implementation of the restrictions for other operators. BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1092353002 Cr-Commit-Position: refs/heads/master@{#28045}
-
- 02 Mar, 2015 2 commits
-
-
Sven Panne authored
BUG=v8:3929 LOG=y R=dcarney@chromium.org Review URL: https://codereview.chromium.org/958053003 Cr-Commit-Position: refs/heads/master@{#26937}
-
Sven Panne authored
BUG=v8:3929 LOG=y R=dcarney@chromium.org Review URL: https://codereview.chromium.org/967243002 Cr-Commit-Position: refs/heads/master@{#26936}
-
- 05 Feb, 2015 1 commit
-
-
Benedikt Meurer authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/900193002 Cr-Commit-Position: refs/heads/master@{#26454}
-
- 30 Jan, 2015 1 commit
-
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/877753007 Cr-Commit-Position: refs/heads/master@{#26346}
-
- 27 Nov, 2014 1 commit
-
-
Michael Stanton authored
The IC system now fully integrates the vector concept and can handle loads and keyed loads vector-based. BUG= R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/754303003 Cr-Commit-Position: refs/heads/master@{#25552}
-
- 28 Oct, 2014 3 commits
-
-
mvstanton@chromium.org authored
A FeedbackNexus is the combination of a feedback vector, a slot(s) in the vector, along with methods to query and manipulate that information in a type-correct way. A CallIC will have a CallICNexus, a LoadIC a LoadICNexus, etc., reflecting the fact that different types of ICs configure their data in unique ways. This CL limits itself to introducing and using the nexus type only for CallICs. A follow-up will use them for Load and KeyedLoadICs for the case when the --vector-ics flag is turned on. The notion of a Nexus is also embedded at the lowest level of the IC class. This makes sense because more ICs should become vector-based in the future. R=ishell@chromium.org Review URL: https://codereview.chromium.org/683933002 Cr-Commit-Position: refs/heads/master@{#24952} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24952 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mvstanton@chromium.org authored
This reverts commit r24945. TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/683883002 Cr-Commit-Position: refs/heads/master@{#24947} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24947 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mvstanton@chromium.org authored
A FeedbackNexus is the combination of a feedback vector, a slot(s) in the vector, along with methods to query and manipulate that information in a type-correct way. A CallIC will have a CallICNexus, a LoadIC a LoadICNexus, etc., reflecting the fact that different types of ICs configure their data in unique ways. This CL limits itself to introducing and using the nexus type only for CallICs. A follow-up will use them for Load and KeyedLoadICs for the case when the --vector-ics flag is turned on. The notion of a Nexus is also embedded at the lowest level of the IC class. This makes sense because more ICs should become vector-based in the future. This CL is based on https://codereview.chromium.org/679073002/ which should land first. BUG= R=ishell@chromium.org Review URL: https://codereview.chromium.org/680883004 Cr-Commit-Position: refs/heads/master@{#24945} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24945 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Oct, 2014 1 commit
-
-
mvstanton@chromium.org authored
BUG=v8:3605 LOG=N R=jkummerow@chromium.org, ulan@chromium.org Review URL: https://codereview.chromium.org/650073002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24732 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Sep, 2014 1 commit
-
-
bmeurer@chromium.org authored
Review URL: https://codereview.chromium.org/618643002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24319 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Sep, 2014 1 commit
-
-
mvstanton@chromium.org authored
CodeStubs use state types defined in ic.h, but this has the unfortunate effect of spreading ic.h all over the place. Instead, define these shared state types in ic-public.h and allow ic.h to concern itself with internal state change of the ICs. More work could/should be done here, but this is a first step. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/565873002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-