[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