I prefer introducing high-level instructions that internally choose the
correct
implementation, rather than using a script (and C++ macros) to selectively
replace instructions. Macros like __k and __n seem very error-prone to me.
At the same time, I think it's overkill to over-specify the semantics of
certain
instructions (eg MoveReturnAddress). The move instruction itself doesn't
care
that it's a return address, it just cares about the size. The offset does,
however, care that it needs to find the offset for a return address. So it
made
more sense that the Operand was specific to the return address, rather than
the
current Operand(rsp, 0). The same thing is true for this MoveInteger64. As
danno
mentioned, movq seems fine since it'll always be 64bit.
And so that's what I meant with using movp; which I thought would mean
either
movq on x64 or movl on ia32 (could be that I'm just confused and that we
need
another name for that). For other cases, where it's either always 64bit or
32bit
independent of the architecture, we should just keep on using either movq or
movl; rather than introducing new copies such as MoveQuadWord.
So I wouldn't replace *all* movq by movp, but only those that have to
either be
movq or movl. Those that are always movq stay movq.
Does this make sense?
https://codereview.chromium.org/64313002/
--
--
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.
