On 2014/02/14 13:44:17, rmcilroy wrote:
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.
Ping?
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.
