https://codereview.chromium.org/160423002/diff/160001/src/a64/code-stubs-a64.cc
File src/a64/code-stubs-a64.cc (right):
https://codereview.chromium.org/160423002/diff/160001/src/a64/code-stubs-a64.cc#newcode556
src/a64/code-stubs-a64.cc:556: __ Push(scratch1, scratch2);
On 2014/02/14 12:57:38, jbramley wrote:
On 2014/02/14 12:45:07, rmcilroy wrote:
> On 2014/02/13 14:20:14, jbramley wrote:
> > This is probably the only stub that preserves its registers. It
took us a
> little
> > while to realise that this didn't need to be marked as a call.
Could you add
a
> > comment to the call site please?
>
> I'm not sure what you mean here? What would you mean by "marked as a
call" -
it
> is called with CallStub, which typically doesn't respect
caller/callee saved
> register call semantics. As far as I can tell RecordWriteStub does
the same
> thing (for scratch1_/scratch2_ and it doesn't have any special
"marked as
call"
> or comment that I can see.
At the moment, MarkAsCall preserves every live value (if I remember
correctly),
even callee-saved values, because the call might do a GC.
Our stubs don't really have an ABI; we tend to be cautious and assume
that they
can clobber anything except the stack. We inherited this from ARM, but
we'd like
to improve this later.
It's perfectly Ok to define a stub that explicitly doesn't clobber any
registers, but it's unusual (for A64) so it needs a comment at the
call site. If
I see CallStub, I normally think "clobber everything".
Ok, done. Just FYI - I expect we will be adding more of these "short
non-call-marked" stubs in the future since we are planning on doing some
work to avoid inlining exceptional cases (such as this) and move that
work into stubs instead to reduce code-bloat.
RecordWriteStub is a bit weird and I think I have some TODOs in there
to clean
it up. At the moment, the underlying RecordWrite() overwrites some
input
registers, for example.
> > Also, it would be more efficient to ask for temp registers than to
> > unconditionally preserve the scratch registers. Is there any way
to arrange
> > that? Even using DefineFixed would be better than unconditionally
preserving
> > them on the stack.
>
> If we allocated temp registers then we would need to allocate these
every time
> MacroAssembler::TruncateDoubleToI() was called, even though they
would only
> actually be used if we had to call into the stub (which is fairly
infrequent
> since most situations are successful with the inline code). It's a
trade off
> between additional register pressure (for every TruncateDoubleToI)
verses
> additional push/pop overhead, but only in situations where we need
to call out
> to the stub. When I did this for Arm there was no noticeable
overhead
increase
> caused by the additions of the push/pops so I would prefer to do
that here too
> unless you strongly disagree.
That makes sense. I'd forgotten that the stub is actually the rare
case, so the
impact of the push and pop is minimal anyway.
https://codereview.chromium.org/160423002/
--
--
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.
