[LLVMdev] Backend optimizations

Herbie Robinson HerbieRobinson at verizon.net
Tue Jan 27 07:49:12 PST 2015


On 1/26/15 9:33 AM, Rinaldini Julien wrote:
> The goal here is to add some obfuscation to the final binary, so some
> performance loss is excepted!
You could solve the unbalanced call/return by replacing the return with 
a pop and jump, but I don't think that's going to fool anybody for long...

But this brings forth an idea: one interesting optimization for for 
internal subroutines that are not internally recursive would be to:

1.   Put the return address into a temp.
2.  Jump to the entry point (using a PHI instruction to collect the 
arguments).
3.  Use a computed branch on the temp instead of return.

This would be applicable for things that are too big to inline and don't 
allocate a lot of variables on the stack frame.  One wouldn't want to do 
it all the time, because kernel coders will occasionally segregate stub 
routines that need large stack for temporary storage out of the main 
data path to keep the frame size down in hot paths (to reduce cache 
footprint).  I've gotten 5-10% improvement in overall performance by 
doing that (with putnext, which was allocating a very large frame to 
format an error message that essentially never occurred).

Of course, now somebody will tell me LLVM is already doing this one :-)



More information about the llvm-dev mailing list