You probably don't need this on MIPS. We needed something like this on ia32
for
SSE2. The intent of that change (a few weeks ago) was to avoid saving FP
regs in
the snapshot, not only because we don't yet know if we have SSE2, but also
because the snapshot usages of the record write stub code didn't need to
save FP
regs for the stores.
Paul, thanks also for noticing the logical error in the use of VFP32DREGS! I
really wanted to avoid saving FP regs at all. A more logical fix might be to
replace the IsSafeForSnapshot() statement with !Serializer::enabled(). I
will
follow up on the question of soft-float...indeed, maybe I do need to always
save
FP regs on ARM, and therefore need another solution for the snapshot.
On 2013/04/18 23:26:28, Paul Lind wrote:
Perhaps I am missing the intent of the original CL, but I do not think
this
applies to MIPS. Now that soft-float is deprecated on ARM and MIPS, I
believe
we
always need to save FP regs. But on ARM, there is a question of "how
many",
since some cores have 16 d-regs, and others have 32 d-regs.
In Michael's CL this
expression: "CpuFeatures::IsSafeForSnapshot(VFP32DREGS) ?
kSaveFPRegs : kDontSaveFPRegs" evaluates to kDontSaveFPRegs if there are
only
16
d- regs. So in StoreBufferOverflowStub::Generate() NO d-regs would get
saved.
That does not quite make sense to me, maybe Michael or you can explain
what I
am
missing here.
MIPS does not have a variable number, so your similar expression will
always
evaluate to kSaveFPRegs, which is what's in the code now. So it won't
hurt us
to
delay porting this a day, until we understand.
https://codereview.chromium.org/14368002/
--
--
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/groups/opt_out.
