On 2015/03/26 07:20:33, Sven Panne wrote:
On 2015/03/25 19:32:22, michael_dawson wrote:
> Ok with the latest changes we've removed the excludes from the test
status
files
> so don't have any skips other than regress/regress-1132 which you
indicated
> would be ok.
Nice! And our waterfall c
On 2015/03/25 19:32:22, michael_dawson wrote:
Ok with the latest changes we've removed the excludes from the test status
files
so don't have any skips other than regress/regress-1132 which you
indicated
would be ok.
Nice! And our waterfall columns for PPC now have a tendency to be
green..
Ok with the latest changes we've removed the excludes from the test status
files
so don't have any skips other than regress/regress-1132 which you indicated
would be ok.
I have a set of small changes to address compilation failures on AIX due to
recent changes but after that my plan would be to
On 2015/03/17 07:25:38, Sven Panne wrote:
On 2015/03/16 22:07:23, michael_dawson wrote:
> Ok, now that the PPC buildbots are up and running and
> frequently passing, I think
> the next step would be to get back to looking our
> constant pool solution for PPC. As a first step
> I could build a re
On 2015/03/16 22:07:23, michael_dawson wrote:
Ok, now that the PPC buildbots are up and running and
frequently passing, I think
the next step would be to get back to looking our
constant pool solution for PPC. As a first step
I could build a review which has our never version
which does not depe
On 2015/03/07 01:57:56, michael_dawson wrote:
New review to cleanup serialize.cc and bring ppc dirs to be current
with changes over the last week. At time of submission it was current
with latest commits and ppc and ppc64 compiled/ran.
https://codereview.chromium.org/986553005/
Ok, now that
New review to cleanup serialize.cc and bring ppc dirs to be current
with changes over the last week. At time of submission it was current
with latest commits and ppc and ppc64 compiled/ran.
https://codereview.chromium.org/986553005/
https://codereview.chromium.org/882263003/
--
--
v8-dev mailin
On 2015/02/25 21:04:38, michael_dawson wrote:
On 2015/02/25 07:41:25, Sven Panne wrote:
> On 2015/02/24 22:33:45, michael_dawson wrote:
> > In terms of turning on the build bots and getting test coverage would
> > this be in simulated PPC mode ?
>
> As a first step, yes. I don't know what the pla
On 2015/02/25 07:41:25, Sven Panne wrote:
On 2015/02/24 22:33:45, michael_dawson wrote:
> In terms of turning on the build bots and getting test coverage would
> this be in simulated PPC mode ?
As a first step, yes. I don't know what the plans are for bots with real
PPC
HW,
but even if/when
On 2015/02/24 22:33:45, michael_dawson wrote:
In terms of turning on the build bots and getting test coverage would
this be in simulated PPC mode ?
As a first step, yes. I don't know what the plans are for bots with real
PPC HW,
but even if/when we have such bots, the PPC simulator bots woul
I think we should totally ignore any kind of optimizations for now, our
top
priority is getting the PPC port integrated into the system with
basically no
changes outside the PPC directory, have build bots, test coverage,
In terms of turning on the build bots and getting test coverage would
t
On 2015/02/23 17:29:26, michael_dawson wrote:
For this particular case the Octane benchmark shows that
replacing the multi-instruction mov sequence (2 instructions
for 32-bit, but 5 instructions for 64-bit), where possible,
with a load from the constant pool yields about a 3%
performance improvem
On 2015/02/23 08:00:03, Sven Panne wrote:
On 2015/02/20 21:52:13, michael_dawson wrote:
> At the very least we are going to need changes in the common code to
allow
us
to
> maintain a dedicated constant pool register and slot in the stack frame.
This
is
> because Power architecture does not
Just a remark: We can land the kBootCodeSizeMultiplier change alone, of
course.
https://codereview.chromium.org/882263003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-
On 2015/02/20 21:52:13, michael_dawson wrote:
At the very least we are going to need changes in the common code to
allow us
to
maintain a dedicated constant pool register and slot in the stack frame.
This
is
because Power architecture does not support pc-relative loads.
We can limit this wi
On 2015/02/20 08:51:52, Sven Panne wrote:
tl;dr The kBootCodeSizeMultiplier change is OK, but the OOL constant pool
is
broken and anything related to it should not be touched at all.
Longer version: We want to remove the OOL constant pool (probably in the
next
quarter) and do something dif
tl;dr The kBootCodeSizeMultiplier change is OK, but the OOL constant pool is
broken and anything related to it should not be touched at all.
Longer version: We want to remove the OOL constant pool (probably in the
next
quarter) and do something different, probably architecture-dependent. The
l
On 2015/02/18 10:08:04, Jakob wrote:
I would think that fixing the existing OOL constant pool implementation
is a
lot
less work than implementing a new one.
I'm not sure whether the existing implementation should be kept if you
end up
deciding to do your own thing, but I would err on the s
I would think that fixing the existing OOL constant pool implementation is
a lot
less work than implementing a new one.
I'm not sure whether the existing implementation should be kept if you end
up
deciding to do your own thing, but I would err on the side of caution and
keep
it. Ross tells
Sorry for the late reply I was out at the Node summit last week. Matt is
investigating the alternate solution outlined in his comment above. Based
on what we learn from that we'll decide if we want to use that alternative
or fix the existing OOL implementation.
If we decide to pursue the altern
it's currently disabled because it (a) tanks performance
This is not quite true - it regressed Splay.Latency (~20%), but was
performance
neutral on the other benchmarks on Arm
and the overall regression on Octane was pretty small (~1-2%). It was
enabled
for quite some time on Arm without
Inline constant pools aren't an immediately ideal solution due to the
fact that the Power architecture does not support pc-relative loads.
I can, however, imagine a hybrid solution where:
(a) constants are emitted in the same buffer as the code (like
inline pools but most likely after
I've added 2 people who probably know more about our constant pool plans
than I
do... :-)
https://codereview.chromium.org/882263003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google G
On 2015/02/06 07:28:00, Sven Panne wrote:
https://codereview.chromium.org/882263003/diff/1/src/globals.h
File src/globals.h (right):
https://codereview.chromium.org/882263003/diff/1/src/globals.h#newcode77
src/globals.h:77: #define V8_OOL_CONSTANT_POOL 1
FYI (after some internal discussions):
https://codereview.chromium.org/882263003/diff/1/src/globals.h
File src/globals.h (right):
https://codereview.chromium.org/882263003/diff/1/src/globals.h#newcode77
src/globals.h:77: #define V8_OOL_CONSTANT_POOL 1
FYI (after some internal discussions): The OOL constant pool is
currently broken (v
25 matches
Mail list logo
