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

Jonas Wagner via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 19 09:40:16 PST 2016


I’m thinking about using LLVM to implement a limited form of self-modifying
code. Before diving into that, I’d like to get some feedback from you all.

*The goal:* I’d like to add “optional” code to a program that I can enable
at runtime and that has zero (i.e., as close to zero as I can get) overhead
when not enabled.

*Existing solutions:* Currently, I can guard optional code using a branch,
something like br i1 %cond, label %optional, label %skip, !prof !0. Branch
weights ensure that the branch is predicted correctly. The overhead of this
is not as low as I’d like, though, because the branch is still present in
the code and because computing %cond also has some cost.

*The idea:* I’d like to have a branch that is the same as the example
above, but that gets translated into a nop instruction. Preferably some
unique nop that I can easily recognize in the binary, and that has the same
size as an unconditional branch instruction. Then, I could use a framework
such as DynInst to replace that nop with an unconditional branch
instruction at run-time.

My questions to the community would be:

   - Does the idea make sense, or am I missing a much simpler approach?
   - What would be the easiest way to obtain the desired binary? Adding a
   new TerminatorInstruction sounds daunting, is there something simpler?

I also wonder whether I could even expects speedups from this? Are nop
instructions actually cheaper than branches? Would modifying the binary at
run-time play well enough with caches etc.? These are probably not
questions for the LLVM mailing list, but if anybody has good answers they
are welcome.

Looking forward to hearing your thoughts,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160119/e206da4d/attachment.html>

More information about the llvm-dev mailing list