- 13 Jul, 2015 1 commit
-
-
ishell authored
NON_CONTEXTUAL ~> INSIDE_TYPEOF CONTEXTUAL ~> NOT_INSIDE_TYPEOF Review URL: https://codereview.chromium.org/1227893005 Cr-Commit-Position: refs/heads/master@{#29611}
-
- 30 Jun, 2015 1 commit
-
-
conradw authored
Revert "Revert relanded strong property access CL" Regression issues should be solved. Initial patchset is the original, subsequent patchsets are the fixing modifications. This reverts commit 4ac7be56. BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1199983002 Cr-Commit-Position: refs/heads/master@{#29384}
-
- 19 Jun, 2015 2 commits
-
-
conradw authored
Reason: Regressions in various benchmarks. Revert "Revert of Revert of [strong] Implement strong mode restrictions on property access (patchset #1 id:1 of https://codereview.chromium.org/1189153002/)" This reverts commit 41405c04. Revert "X87: Revert of Revert of [strong] Implement strong mode restrictions on property access." This reverts commit 48de5f4d. Revert "Fix overlapping KeyedLoadIC bitfield." This reverts commit 4e6c956a. Revert "MIPS64: Fix 'Revert of Revert of [strong] Implement strong mode restrictions on property access'." This reverts commit 74f97b0d. BUG= Review URL: https://codereview.chromium.org/1199493002 Cr-Commit-Position: refs/heads/master@{#29166}
-
conradw authored
BUG= LOG=N Review URL: https://codereview.chromium.org/1192383003 Cr-Commit-Position: refs/heads/master@{#29148}
-
- 18 Jun, 2015 3 commits
-
-
conradw authored
Revert of Revert of [strong] Implement strong mode restrictions on property access (patchset #1 id:1 of https://codereview.chromium.org/1189153002/) Reason for revert: Issue was ultimately caused/fixed by https://codereview.chromium.org/1194673002/ Original issue's description: > Revert of [strong] Implement strong mode restrictions on property access (patchset #23 id:460001 of https://codereview.chromium.org/1168093002/) > > Reason for revert: > Speculative revert, maybe breaks GC-stress > > http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/808 > > Original issue's description: > > [strong] Implement strong mode restrictions on property access > > > > Implements the strong mode proposal's restrictions on property access. > > > > To be fully explored in a followup: proxies, interceptors, access checks, load from super > > > > BUG=v8:3956 > > LOG=N > > > > Committed: https://crrev.com/85dbfb9a389e7b21bd2a63862202ee97fc5d7982 > > Cr-Commit-Position: refs/heads/master@{#29109} > > TBR=rossberg@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:3956 > > Committed: https://crrev.com/407657b706711fd5f8d417841e24b284886f3776 > Cr-Commit-Position: refs/heads/master@{#29115} TBR=rossberg@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1185343005 Cr-Commit-Position: refs/heads/master@{#29122}
-
conradw authored
Revert of [strong] Implement strong mode restrictions on property access (patchset #23 id:460001 of https://codereview.chromium.org/1168093002/) Reason for revert: Speculative revert, maybe breaks GC-stress http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/808 Original issue's description: > [strong] Implement strong mode restrictions on property access > > Implements the strong mode proposal's restrictions on property access. > > To be fully explored in a followup: proxies, interceptors, access checks, load from super > > BUG=v8:3956 > LOG=N > > Committed: https://crrev.com/85dbfb9a389e7b21bd2a63862202ee97fc5d7982 > Cr-Commit-Position: refs/heads/master@{#29109} TBR=rossberg@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3956 Review URL: https://codereview.chromium.org/1189153002 Cr-Commit-Position: refs/heads/master@{#29115}
-
conradw authored
Implements the strong mode proposal's restrictions on property access. To be fully explored in a followup: proxies, interceptors, access checks, load from super BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1168093002 Cr-Commit-Position: refs/heads/master@{#29109}
-
- 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}
-
- 22 May, 2015 1 commit
-
-
mvstanton authored
This follows the logic of the load ics, in that the base extra ic state is better encapsulated. Introduce flag vector_stores to aid development of vector-based store ics. BUG= R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1151253004 Cr-Commit-Position: refs/heads/master@{#28576}
-
- 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}
-
- 20 Apr, 2015 1 commit
-
-
Ross McIlroy authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/1088993003 Cr-Commit-Position: refs/heads/master@{#27937}
-
- 02 Mar, 2015 1 commit
-
-
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 2 commits
-
-
Benedikt Meurer authored
This reverts commit 6a4c0a3b and commit 0deaa4b6 for breaking GCC bots. TBR=svenpanne@chromium.org Review URL: https://codereview.chromium.org/893533003 Cr-Commit-Position: refs/heads/master@{#26342}
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/888613002 Cr-Commit-Position: refs/heads/master@{#26340}
-
- 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
-