Relocinfo contains more info than is necessary for literal pools, so using a
dedicated structure (like in arm64) would also save space. That being said
it is
only worth doing if the inline pool remains supproted.
https://codereview.chromium.org/555943003/diff/1/src/arm/assembler-arm.cc
File src/arm/assembler-arm.cc (right):
https://codereview.chromium.org/555943003/diff/1/src/arm/assembler-arm.cc#newcode477
src/arm/assembler-arm.cc:477: max_num_32_bit_reloc_info_ =
This may not work. kMaxNumPending[32|64]RelocInfo were define as
LiteralPoolRange / InstructionSize so that you never need to check if
you are going to overflow the array of RelocInfo since the pool will be
emitted before that happens. There is no such guarantee now. And if
buffer_size_ is bigger than 4k then we are wasting space.
https://codereview.chromium.org/555943003/
--
--
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.
