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

[Jonas Wagner via llvm-dev]

Thanks for the information. This has been very useful!

Patch points indeed *almost* do what I need. I will try to build a similar
solution.

Self-modifying code for truly zero-overhead (when not enabled)
> instrumentation is a real thing (look at e.g. DTrace pid provider) but
> unless the number of instrumentation point is very large (100's of
> thousands? millions?) or not known beforehand (both are true for DTrace),
> the cost of a branch will be negligible.
>

In the use case that I have in mind, there are indeed a large number of
instrumentation points. To give a concrete example of what I'd like to
achieve, consider Clang's -fsanitize flag. These sanitizers add thousands
of little independent bits of code to the program, e.g., memory access
checks. Code that is very useful but also slows the program down. I'd like
to transform this code into zero-overhead instrumentation that I can enable
selectively.

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.
>

I'm still not 100% sure whether the `nop <-> br` conversion is the best
approach. I've considered some alternatives:
- Branches where the condition is a flag in memory. My early experiments
were too slow :(
- Conditional branches along with some other way to control the flags
register. I'm afraid of the side effects this might have.

For now, transforming an `llvm.experimental.patchpoint` into an
unconditional branch looks most promising. I just need to figure out how to
trick LLVM into laying out basic blocks the right way (and not eliminating
those that are unreachable due to not-yet-transformed branches).

Cheers,
Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160120/3e55ff9b/attachment.html>