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#newcode539
src/a64/code-stubs-a64.cc:539: void
DoubleToIStub::Generate(MacroAssembler* masm) {
On 2014/02/14 12:45:07, rmcilroy wrote:
Looks like the is_truncating() option isn't supported by any
arches, we should maybe just drop the option...
If we do, we should probably rename the stub too, but that's something
to worry about later.
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: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".
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/diff/160001/src/a64/code-stubs-a64.cc#newcode561
src/a64/code-stubs-a64.cc:561: __ Push(double_scratch);
On 2014/02/14 12:45:07, rmcilroy wrote:
I can't - Push() barfs that the registers are of different types
(Register and
DoubleRegister).
Ah, yes, sorry.
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.
