[LLVMdev] GSoC proposal: Common memory safety instrumentation and optimization passes for LLVM
criswell at illinois.edu
Fri Apr 6 10:34:02 CDT 2012
On 4/6/12 10:29 AM, Kostya Serebryany wrote:
> On Fri, Apr 6, 2012 at 7:50 AM, John Criswell <criswell at illinois.edu
> <mailto:criswell at illinois.edu>> wrote:
> On 4/6/12 12:50 AM, Kostya Serebryany wrote:
>> I'd like some similar work to be done, although I view it a bit
>> This might be a separate analysis pass that knows nothing about
>> ASAN or SAFECode
>> and appends metadata nodes to memory access instructions saying
>> things like
> This is a good idea but is the wrong way to implement the idea.
> LLVM passes are not required to preserve metadata, and even if
> they were required to do so, there would always be a pass with a
> bug that would fail to preserve the metadata properly. It's an
> approach that can lead to undesired headaches. Furthermore,
> you're not guaranteed that an instruction that was deemed safe
> earlier is safe after transformation; there are optimizations that
> LLVM can do on C code exhibiting undefined behavior that can
> change it from memory safe to memory-unsafe code.
> Oh, surely the analysis pass should be called directly from the
> instrumentation pass, so that no other pass can interfere.
> But a separate pass that marks insns with metadata might be easier to
An analysis pass can have a print() method that prints its results. You
could use something like that to test it.
My point is that metdata should not be used to communicate information
from an analysis pass to a transform pass; the transform pass should
simply use getAnalysis() to get a pointer to the analysis pass and then
query the analysis pass directly. If you want to write a transform pass
that queries the analysis pass and puts metadata on instructions as a
debugging aid, that would be fine.
-- John T.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LLVMdev