On 2014/09/19 08:38:59, Rodolph Perfetta wrote:
On 2014/09/18 14:03:25, Rodolph Perfetta wrote:
> 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.
OK scratch that, I missed the Min ...
Sorry
After offline discussions, I am inclined to go with adjusting the stack
limit.
That would be safer to merge back to 3.28 and wouldn't introduce new
performance
regressions: https://codereview.chromium.org/583163002/
If you agree, I'll abandon this CL.
https://codereview.chromium.org/555943003/
--
--
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-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
