[llvm-dev] Adding support for self-modifying branches to LLVM?

[Jonas Wagner via llvm-dev]

Hi,

I'm coming back to this old thread with data about the performance of NOPs.
Recalling that I was considering transforming NOP instructions into
branches and back, in order to dynamically enable code. One use case for
this was enabling/disabling individual sanitizer checks (ASan, UBSan) on
demand.

I wrote a pass which takes an ASan-instrumented program, and replaces each
ASan check with an llvm.experimental.patchpoint intrinsic. This intrinsic
inserts a NOP of configurable size. It has otherwise no effect on the
program semantics. It does prevent some optimizations, presumably because
instructions cannot be moved across the patchpoint.

Some results:
- On SPEC, patchpoints introduce an overhead of ~25% compared to a version
where ASan checks are removed.
- This is almost half of the cost of the checks themselves.
- The results are similar for NOPs of size 1 and 5 bytes.
- Interestingly, the results are similar for NOPs of 0 bytes, too. These
are patchpoints that don't insert any code and only inhibit optimizations.
I've only tested this on one benchmark, though.

To summarize, only part of the cost of NOPs is due to executing them. Their
effect on optimizations is significant, too. I guess this would hold for
branches and sanitizer checks as well.

Best,
Jonas


On Thu, Jan 21, 2016 at 11:52 PM Jonas Wagner <jonas.wagner at epfl.ch> wrote:

> Hello,
>
> There is some data on this, e.g, in “High System-Code Security with Low
> Overhead” <http://dslab.epfl.ch/proj/asap/#publications>. In this work we
> found that, for ASan as well as other instrumentation tools, most overhead
> comes from the checks. Especially for CPU-intensive applications, the cost
> of maintaining shadow memory is small.
>
> How did you measure this? If it was measured by removing the checks before
> optimization happens, then what you may have been measuring is not the
> execution overhead of the branches (which is what would be eliminated by
> nop’ing them out) but the effect on the optimizer.
>
> Interesting. Indeed this was measured by removing some checks and then
> re-optimizing the program.
>
> I’m aware of some impact checks may have on optimization. For example,
> I’ve seen cases where much less inlining happens because functions with
> checks are larger. Do you know other concrete examples? This is definitely
> something I’ll have to be careful about. Philip Reames confirms this, too.
>
> On the other hand, we’ve also found that the benefit from removing a check
> is roughly proportional to the number of cycles spent executing that
> check’s instructions. Our model of this is not very precise, but it shows
> that the cost of executing the check’s instructions matters.
>
> I'll try to measure this, and will come back when I have data.
>
> Best,
> Jonas
> ​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/2eb19061/attachment.html>