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 support pc-relative loads.
> We can limit this with a PPC specific guard name but we thought this
could
also
> be leveraged other platforms like MIPs.
I don't think we need any changes in the common code at all for this:
Somehow
you need to reload the constant pool register at various places (e.g.
after
calls etc.), and there is no fundamental reason why this has to be done
from
the
stack frame. You can just reload the absolute address again, IIRC this
needs 2
instructions on PPC, so you need some kind of relocation info for this
instruction pair. I don't know if you already have this kind of
relocation,
but
ARM (and probably MIPS, too) has it. It's not obvious at all that this is
less
efficient than a memory load from the fram. Let's first get things
running on
PPC with minimal changes to the rest of the system. Tuning can be done
later
after extensive benchmarking.
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 improvement
From what we understand reloading the absolute address as
suggested above, we think it would still require
changes to the common code. It would require an internal
reference relocation type which is not currently
supported by the serializer, and support to record the constant
pool's location in the Code object to be able to proplerly
apply relocations. We also don't believe that it would yield
the same performance improvement, particularly on 64 bit as
the extra path-length dominates the instruction groups.
The addition of a 5 instruction mov after every call will also
significantly inflate our code size.
While you sort out how this will be handled across platforms we'd
like to be able to improve performance for PPC with the
understanding that it will be reworked to fit into the
common solution once its decided.
Would it be possible to set up a conference call to discuss, it
might be easier ?
> Was your concern with the way we guarded changes in the common code
(using
existing
> out of line flags) for the base register and slot or that we require
> that support at all in the alternate approach.
Regarding the guards: Assume that no OOL-related #defines exist, they will
probably die. Introducing more usages will just make ripping them out
later
more
complicated. Regarding register/slot: See above.
Fair enough.
https://codereview.chromium.org/882263003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
