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

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Jonas Wagner via llvm-dev" <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Tuesday, January 19, 2016 11:40:16 AM
> Subject: [llvm-dev] Adding support for self-modifying branches to
> LLVM?

> Hi,
> 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.
If you've not already, you'll want to look at this: http://llvm.org/docs/StackMaps.html (it does not quite do what you want, but it should give you some idea on how you might proceed). 

-Hal 

> Looking forward to hearing your thoughts,
> Jonas
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160119/8e3bf583/attachment.html>