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 improvement
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, etc.
Even if
we paid 20%, I wouldn't care right now. Every hack and complication we
introduce
now will only slow the whole process down.
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.
As stated above, let's forget about performance tweaks for now and just get
things working in the easiest possible way. In our concrete case: Follow the
MIPS64 port and just load the constants directly in the code stream (see
MacroAsssembler:li in MIPS64). This way we don't need any kind of magic
outside
the port.
Regarding the "#if V8_TARGET_ARCH_PPC" in serialize.cc: Would it be
possible to
remove that by e.g. introducing a new RelocInfo::Mode which is just
generated
for the PPC port, but otherwise architecture-independent? We do this for
other
stuff already, see e.g. VENEER_POOL. As it is, this a bit of a hack and will
probably cause pain later.
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.
Again, performance is not an issue at all at this point in time.
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.
