[LLVMdev] GSoC proposal: Common memory safety instrumentation and optimization passes for LLVM

[John Criswell]

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
>>     differently.
>>     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 
> test.

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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120406/d740c9a8/attachment.html>