On 2015/07/02 14:29:02, Yang wrote:
On 2015/07/02 14:25:18, Yang wrote:
> On 2015/07/02 13:59:48, rmcilroy wrote:
> >
https://codereview.chromium.org/1217673003/diff/1/src/arm/assembler-arm.cc
> > File src/arm/assembler-arm.cc (left):
> >
> >
>
https://codereview.chromium.org/1217673003/diff/1/src/arm/assembler-arm.cc#oldcode3859
> > src/arm/assembler-arm.cc:3859: for (int j = 0; j < i; j++) {
> > By removing this sharing you are going to increase the size of the
generated
> Arm
> > code which is not ideal (especially considering we are trying all we
can
to
> > reduce heap usage on Android). Is there another way we could deal
with the
> > duplicates (e.g., having some way for the debugger to estimate the
size of
the
> > constant pool ahead of time?).
> >
> > Happy to VC about this if it helps.
>
> I'd like to have correctness first. This bug is not new, it just wasnt
exposed
> before. Currently neither the reloc info nor the constant pool header
reports
> the correct number of constants and there is no way to figure out after
the
fact
> how many constants we have.
It might be new - https://codereview.chromium.org/1162993006/ changed this
quite
a lot and might have changed when we do the deduping in relation to
emitting the
constants.
> We could deduplicate while inserting, but that seems more involved, and
I'd
like
> to not have this block this bug fix.
or we could defer emitting the constants until after deduplicating.
This would work for me. You should be able to use the merged_index field in
ConstantPoolEntry to do deduping in-place in the pending_xx_bit_constants_
array
before you go about emitting the constants. WDYT?
https://codereview.chromium.org/1217673003/
--
--
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.
