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): The OOL constant pool is currently
broken
(violates the marking invariant), furthermore, we might remove it in the
future.
So it would be good to avoid using it from the start. What's the reason
you
want
to enable it? Perhaps there's another way to achieve your goals.
We gravitated toward OOL constant pools because they map fairly well
to the way traditionally compiled code on the Power platform handles
global data. That is, via a TOC (table of contents) pointer placed in
a reserved register pointing to a table of data.
In the absence of a constant table, we are forced to construct address
constants using bitwise operations. For 64-bit, in the general case,
this requires five instructions:
lis r8, <A> // load bits 63-48
ori r8, r8, <B> // load bits 47-32
rldicr r8, r8, 32, 31 // shift into high word
oris r8, r8, <C> // load bits 31-16
ori r8, r8, <D> // load bits 15-0
This is compared to a single instruction load from the constant pool.
The additional path-length caused by this has a significant
performance penalty. In conjunction with other optimizations to
reduce path length, the effect is even larger (e.g. due to instruction
grouping on Power8).
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 the code rather than
interspersed)
in conjunction with:
(b) a requirement that a reserved register hold the base of the
table with logic to set it up in the prologue and save/restore to a
dedicated slot in the frame (like OOL pools).
This may or may not be an improvement depending on the details of the
OOL issue you referenced. It would still require some support and
maintenence in the common code for the general mechanism, but would
allow the constant pool array object to be done away with.
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.
