[llvm-dev] Adding support for self-modifying branches to LLVM?
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 21 13:33:08 PST 2016
On 01/19/2016 09:04 PM, Sean Silva via llvm-dev wrote:
>
> AFAIK, the cost of a well-predicted, not-taken branch is the same as a
> nop on every x86 made in the last many years.
> See http://www.agner.org/optimize/instruction_tables.pdf
> <http://www.agner.org/optimize/instruction_tables.pdf>
> Generally speaking a correctly-predicted not-taken branch is basically
> identical to a nop, and a correctly-predicted taken branch is has an
> extra overhead similar to an "add" or other extremely cheap operation.
Specifically on this point only: While absolutely true for most
micro-benchmarks, this is less true at large scale. I've definitely
seen removing a highly predictable branch (in many, many places, some of
which are hot) to benefit performance in the 5-10% range. For instance,
removing highly predictable branches is the primary motivation of
implicit null checking. (http://llvm.org/docs/FaultMaps.html). Where
exactly the performance improvement comes from is hard to say, but,
empirically, it does matter.
(Caveat to above: I have not run an experiment that actually put in the
same number of bytes in nops. It's possible the entire benefit I
mentioned is code size related, but I doubt it given how many ticks a
sample profiler will show on said branches.)
p.s. Sean mentions down-thread that most of the slowdown from checks is
in the effect on the optimizer, not the direct impact of the
instructions emitted. This is absolutely our experience as well. I
don't intend for anything I said above to imply otherwise.
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/5c7b9209/attachment.html>
More information about the llvm-dev
mailing list