Question about Safecode optimizations

Hello,

I have been using Safecode to add bounds checks to some programs and am getting very high running times for those programs. In average, the slowdown is up by a factor of 30, sometimes even 90. Is there a way to improve on this?

I have followed the instructions about installing and using the Link Time Optimizer on this page: http://safecode.cs.illinois.edu/docs/Install.html

Still, the runtime of the compiled files is about the same.

Are there any additional instructions that I am missing? Any other options that may be needed?

Thank you
Rigel

Dear Rigel,

The current version of SAFECode for LLVM 3.2 does not currently use all the fancy optimizations developed in previous research (namely, Dhurjati's et. al.'s type-safe load/store check elimination optimization). As a result, it is essentially Jones/Kelley. The source code for the optimizations are still there; they simply aren't enabled.

The reason for this is that we opted to make SAFECode a robust debugging tool first and then make its optimizations and soundness features robust later. However, I graduated before we could make that code robust.

If you want a production quality tool, I recommend Address Sanitizer. If you want to use SAFECode and get the best speed out of it, be sure to use at least -O2 optimization or higher; using the SAFECode libLTO plugin may also help (though it may also hurt performance by making more checks complete).

As an FYI, we have a Google Summer of Code student working on Baggy Bounds with Accurate Checking (an extension of Baggy Bounds Checking that can do accurate bounds checking by storing extra meta-data within the padding area). When sufficiently robust, this should speed up SAFECode significantly. The goal is to get infrastructure up and running which we will be using within my research group; I hope that it will also be useful to others.

On a final note, while good run-time check techniques like Address Sanitizer and Baggy Bounds improve performance considerably, my hunch is that we won't get *really* good performance without aggressive inter-procedural compiler optimization.

Regards,

John Criswell