[LLVMdev] How to make sure llvm.memset intrinsic is not lowered into memset() call?

John Criswell criswell at illinois.edu
Mon Sep 30 08:48:36 PDT 2013

On 9/30/13 9:40 AM, Alexey Samsonov wrote:
> Hi llvmdev!
> There are cases when we want our instrumentation passes for Sanitizer 
> tools to insert llvm.memset.* calls (basically, we want to mark 
> certain region of user memory as (un)addressable by writing magic 
> values for "shadow" of that memory region). llvm.memset are convenient:
> (1) we don't have to manually emit all these n-byte stores in a cycle.
> (2) llvm.memset can be inlined as a platform-specific fast 
> instructions (e.g. SSE).
> But there will be a problem if llvm.memset is lowered into a regular 
> memset() call: sanitizer runtime libraries intercept all memset() 
> calls and treat them as function calls made by user, in particular 
> checking that its arguments point to an addressable "user" memory, not 
> some sanitizer-specific memory regions.
> Can you suggest a way to ensure llvm.memset() is not transformed into 
> memset function()? This intrinsic has <isvolatile> argument, which 
> limits possible optimization of this call, does it make sense to add 
> yet another argument, that would forbid transforming it into function 
> calls?

Dumb question: why not run the ASan instrumentation passes first and 
then run the pass that inserts the calls to llvm.memset()?

Alternatively, why not put the llvm.memset and load/store 
instrumentation into a single pass?  That way, the pass can determine 
which memsets it added itself and which are ones from the original 
program that need instrumentation.

-- John T.

> -- 
> Alexey Samsonov, MSK
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130930/09ef553d/attachment.html>

More information about the llvm-dev mailing list