- 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}
-
- 18 Mar, 2015 1 commit
-
-
loislo authored
I found some strange split in deopt entry points generator. The code for table entry generator had two classes. It is safe to join these classes together and drop virtual. BUG= LOG=n Review URL: https://codereview.chromium.org/1010413003 Cr-Commit-Position: refs/heads/master@{#27264}
-
- 10 Feb, 2015 1 commit
-
-
loislo authored
1) Deoptimizer::Reason was replaced with Deoptimizer::DeoptInfo because it also has raw position. Also the old name clashes with DeoptReason enum. 2) c_entry_fp assignment call was added to EntryGenerator::Generate So we can calculate sp and have a chance to record the stack for the deopting function. btw it makes the test stable. 3) new kind of CodeEvents was added to cpu-profiler 4) GetDeoptInfo method was extracted from PrintDeoptLocation. So it could be reused in cpu profiler. BUG=452067 LOG=n Review URL: https://codereview.chromium.org/910773002 Cr-Commit-Position: refs/heads/master@{#26545}
-
- 05 Dec, 2014 1 commit
-
-
mstarzinger authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/782703002 Cr-Commit-Position: refs/heads/master@{#25680}
-
- 08 Sep, 2014 1 commit
-
-
yangguo@chromium.org authored
R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/552803002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23778 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jul, 2014 1 commit
-
-
danno@chromium.org authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/426233002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Jul, 2014 1 commit
-
-
jarin@chromium.org authored
This reverts "ARM64: Use pair memory access in deoptimizer entry", r20613. It does not really make sense to micro-optimize the deoptimizer as it is the ultra-slow path. Moreover, the original code was easier to read (in addition to being correct). BUG=391313 LOG=N R=ulan@chromium.org Review URL: https://codereview.chromium.org/389583003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22360 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Jun, 2014 1 commit
-
-
mvstanton@chromium.org authored
Centralize a register definition in an IC that provides: 1) symbolic names for the register (like, edx == receiver) 2) defines ordering when passed on the stack Code that implements or uses the IC should use this definition instead of "knowing" what the registers are. Or at least have the definition to validate it's assumptions. As a side effect of avoiding runtime static initializers (enforced by tools/check-static-initializers.sh, neat), I gave ownership of the registers array to CodeStubInterfaceDescriptor. This prompted a cleanup of that struct. R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/352583002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22011 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jun, 2014 1 commit
-
-
rodolph.perfetta@arm.com authored
This is the first patch to improve literal pool handling in arm64. Cleans up assembler/macro-assembler access to literal pools. BUG= R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/318773009 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21723 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 May, 2014 1 commit
-
-
yangguo@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/275433004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Apr, 2014 1 commit
-
-
m.m.capewell@googlemail.com authored
BUG= R=ulan@chromium.org Review URL: https://codereview.chromium.org/228573003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20613 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Mar, 2014 1 commit
-
-
jochen@chromium.org authored
BUG=354405 R=ulan@chromium.org, rodolph.perfetta@arm.com LOG=y Review URL: https://codereview.chromium.org/207823003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20148 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Mar, 2014 1 commit
-
-
alexandre.rames@arm.com authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/204293004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20111 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Mar, 2014 1 commit
-
-
rmcilroy@chromium.org authored
Ensure that the stack contains the correct constant pool pointer when a function deopts. This CL depends on https://codereview.chromium.org/183803022/ landing first. R=ulan@chromium.org Review URL: https://codereview.chromium.org/188063002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19940 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Mar, 2014 1 commit
-
-
alexandre.rames@arm.com authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/194473005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19855 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Mar, 2014 1 commit
-
-
baptiste.afsa@arm.com authored
This patch also modify the crankshaft allocatable double registers because we need this register to be callee saved to be efficient. R=jochen@chromium.org Review URL: https://codereview.chromium.org/190663009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19803 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Mar, 2014 1 commit
-
-
jacob.bramley@arm.com authored
This replaces Tmp0() and Tmp1() with a more flexible scratch register pool. A scope-based utility can temporarily acquire registers from this pool as needed. We no longer have to worry about whether to use Tmp0(), Tmp1() or something else; the scope can just get the next available scratch register. BUG= R=jochen@chromium.org, rmcilroy@chromium.org Review URL: https://codereview.chromium.org/164793003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19768 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Mar, 2014 1 commit
-
-
ulan@chromium.org authored
This adds a pointer to the shared function info into deoptimization data of an optimized code. Whenever the code is deoptimized, it clears the cache in the shared function info. This fixes the problem when the optimized function dies in new space GC before the code is deoptimized due to code dependency and before the optimized code cache is cleared in old space GC (see mjsunit/regress/regress-343609.js). This partially reverts r19603 because we need to be able to evict specific code from the optimized code cache. BUG=343609 LOG=Y TEST=mjsunit/regress/regress-343609.js R=yangguo@chromium.org Review URL: https://codereview.chromium.org/184923002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19635 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Feb, 2014 1 commit
-
-
jkummerow@chromium.org authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/184373004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19607 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Feb, 2014 1 commit
-
-
ulan@chromium.org authored
BUG=v8:3113 LOG=Y R=jochen@chromium.org, rmcilroy@chromium.org, rodolph.perfetta@arm.com Review URL: https://codereview.chromium.org/148293020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19311 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-