On 2014/05/12 13:46:31, titzer wrote:

[...] I am neutral on the usage of CMOV; I just don't want to see them removed
from
the Assembler, because there are sometimes good reasons to use them. If you remove current uses, then maybe we need them later again. When that happens
someone puts them back in, then sometime later someone changes that code,
notices the methods are dead again, removes them again, on and on...

I don't think that we should remove CMOV from the assembler, the question really is: Should we use it? Perhaps we need to have a closer look at the places where
we actually use it, and choose one version or the other, but we should not
depend on the availability of CMOV anymore. Perhaps the "Intel 64 and IA-32
Architectures Optimization Reference Manual" gives some guidelines:

---------------------------------------------
Assembly/Compiler Coding Rule 2. (M impact, ML generality) Use the SETCC and
CMOV
instructions to eliminate unpredictable conditional branches where possible. Do
not do this for
predictable branches. Do not use these instructions to eliminate all
unpredictable conditional branches
(because using these instructions will incur execution overhead due to the
requirement for executing
both paths of a conditional branch). In addition, converting a conditional
branch to SETCC or CMOV
trades off control flow dependence for data dependence and restricts the
capability of the out-of-order
engine. When tuning, note that all Intel 64 and IA-32 processors usually have
very high branch
prediction rates. Consistently mispredicted branches are generally rare. Use
these instructions only if
the increase in computation time is less than the expected cost of a
mispredicted branch.

[Some examples follow]
---------------------------------------------

And some discussions:

http://yarchive.net/comp/linux/cmov.html
https://mail.mozilla.org/pipermail/tamarin-devel/2008-April/000454.html
http://msinilo.pl/blog/?p=1115

So the general theme seems to be: If the branch is very predictable, use a
conditional branch + load, otherwise use SETCC/CMOV. Things vary a bit depending how much you can squeeze in before you need the data dependencies. I think that
the "compacter code" argument is bogus, we have far bigger gains almost
everywhere if we really care about code size. SETCC/CMOV is an out-of-order
execution killer, this should be our biggest concern.

https://codereview.chromium.org/275253004/

--
--
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/d/optout.

Reply via email to