On 2014/07/11 18:05:08, m.m.capewell wrote:
I've looked into this a bit more, and find the problem in my code is that
d15
isn't preserved, as it's not in the set of saved FP registers. The code
that
this patch re-adds works because it preserves d15 by iterating through the
saved
FP registers linearly, though due to this, it fails to preserve d28.
I've yet to discover why it's sensitive to d15, however, as that's a
register
we've reserved for 0.0.
We know what the root cause is - the original code correctly used allocation
index (e.g., allocation index of d20 is 19 - the zero register d15 is not
counted) for registers while the new unified code from r20613 uses the
register
code. This means that data from registers d16-d31 are stored to a wrong
place in
FrameDescription. It should be easy easy to fix - for double registers you
simply need to copy linearly rather than use the code() index. (Note that
for
some bizarre reason the deoptimizer indexes normal registers differently
from
double registers - normal registers use register code index, double
registers
use allocation index, see the difference in Translation::StoreRegister and
Translation::StoreDoubleRegister in deoptimizer.cc.)
However, I am still thinking that this optimization is not worth the
complication in code - as far as I can see, this generated code always
exists
only in one instance, so the memory saving should be small. Or am I missing
something?
https://codereview.chromium.org/389583003/
--
--
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.
