search for: memsetting

On Mon, Sep 30, 2013 at 7:48 PM, John Criswell <criswell at illinois.edu>wrote: > 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 >

On 9/30/13 11:22 AM, Alexey Samsonov wrote: > > On Mon, Sep 30, 2013 at 7:48 PM, John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> wrote: > > 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

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

Hello All, In reviewing source code for OpenSSH-6.1p1, I found instances of deprecated library calls still within various source code files. Examples of deprecated calls are: bzero() (replaced with memset() which is ANSI compliant), index() (replaced with strchr() which is also ANSI compliant). In file 'auth2-jpake.c', I've replaced all the bzero() calls with the equivalent

I have renamed all of the patch files to .txt, which should be acceptable for the mailer daemon at mindrot, per Angel's suggestion. I am attaching the patch files to the email, with the extra space removed and a minor correction made. Bill Parker (wp02855 at gmail dot com) -------------- next part -------------- --- port-linux.c.orig 2012-12-19 17:40:53.231529475 -0800 +++ port-linux.c

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

"memory accesses between the malloc and the memset without an expensive linear scan of the block/function" (1) do you mean just use "memoryIsNotModifiedBetween" function in DSE to check it? x = maloc(..); memset(x, ...) (2) GetUnderlyingObject would give me Value * (from malloc) ? Also another case: memset(s, 0, len); // len > 1 return strlen(s); // optimize to 0 (3)

Hello, I would like to find a way to do this removal properly. I found DSE and "eliminateNoopStore" can be useful for this thing. What I mean? int *test = malloc(15 * sizeof(int)); test[10] = 12; < ----- remove this store memset(test,0,sizeof(int) * 15); I already checked the function "eliminateNoopStore". Looks good, I think I would be to get the value ("A") we

memoryIsNotModifiedBetween is precisely the sort of expensive walk we shouldn't be doing... I'm surprised it hasn't caused any serious issues yet.  Ideally, what we should be doing is using MemorySSA to find a dependency from the memset: if the closest dependency is the malloc, there aren't any stores between the memset and the malloc.  (But we aren't using MemorySSA in

Thanks a lot for your answer. As what you said, I can not have any options to avoid generating this kind of intrinsic for byte code. Is it possible to modify gcc and ask it take all memset liked functions as a general function call? I know this solution is less performance efficient, but I would like to have it for my llvm assembly level modification works. But anyway, thanks for you help. Hao

Can you help a bit? I try to work with DSE but I got the following assert: opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* llvm::Optional<T>::getPointer() [with T = llvm::MemoryLocation]: Assertion `Storage.hasVal' failed. static bool eliminateStrlen(CallInst *CI, BasicBlock::iterator &BBI, AliasAnalysis *AA, MemoryDependenceResults

Resubmittal of patches from November 2010 and a few new ones. Joe Perches (15): s390: Convert vmalloc/memset to vzalloc x86: Convert vmalloc/memset to vzalloc atm: Convert vmalloc/memset to vzalloc drbd: Convert vmalloc/memset to vzalloc char: Convert vmalloc/memset to vzalloc isdn: Convert vmalloc/memset to vzalloc md: Convert vmalloc/memset to vzalloc media: Convert

Resubmittal of patches from November 2010 and a few new ones. Joe Perches (15): s390: Convert vmalloc/memset to vzalloc x86: Convert vmalloc/memset to vzalloc atm: Convert vmalloc/memset to vzalloc drbd: Convert vmalloc/memset to vzalloc char: Convert vmalloc/memset to vzalloc isdn: Convert vmalloc/memset to vzalloc md: Convert vmalloc/memset to vzalloc media: Convert

Resubmittal of patches from November 2010 and a few new ones. Joe Perches (15): s390: Convert vmalloc/memset to vzalloc x86: Convert vmalloc/memset to vzalloc atm: Convert vmalloc/memset to vzalloc drbd: Convert vmalloc/memset to vzalloc char: Convert vmalloc/memset to vzalloc isdn: Convert vmalloc/memset to vzalloc md: Convert vmalloc/memset to vzalloc media: Convert

* if (isStringFromCalloc(Dst, TLI)) should be if (!isStringFromCalloc(Dst, TLI)) but still asserting... 2018-05-22 23:06 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Can you help a bit? > > I try to work with DSE but I got the following assert: > opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* > llvm::Optional<T>::getPointer() [with T

SHEN Hao wrote: > Thanks a lot for your answer. > As what you said, I can not have any options to avoid generating this kind > of intrinsic for byte code. Is it possible to modify gcc and ask it take > all memset liked functions as a general function call? I know this solution > is less performance efficient, but I would like to have it for my llvm > assembly level modification

Hi Teresa, Thank you for the help, adding the "used" attribute worked just fine. It made me realize that the memset function is never inlined by the LTO optimization even without my implementation of the "EmitTargetCodeForMemSet" method. I supposed that the passes dealing with the memset function happen too late, is that correct? Thank you again, Romaric On Fri, Aug 28, 2020

On Mon, May 10, 2010 at 7:19 PM, John Criswell <criswell at uiuc.edu> wrote: > SHEN Hao wrote: >> Thanks a lot for your answer. >> As what you said, I can not have any options to avoid generating this kind >> of intrinsic for byte code. Is it possible to modify gcc and ask it take >> all memset liked functions as a general function call? I know this solution

It looks like the memoryIsNotModifiedBetween assumes the second argument is a store, or some other instruction supported by MemoryLocation::get.  If you're passing in something else, you'll have to compute the MemoryLocation some other way. (Generally, if you're asking a question about an assertion, please include the whole stack trace; it's hard to guess what's happening

Hi, SelectionDAGBuilder doesn't know how to lower a Memcpy and Memset if one of the pointer operands have an address space >= 256. This is understandable since the libc's memcpy / memset don't work for these address spaces. However, both Clang (when copying a struct) and some optimization passes (LoopIdiomRecognize, MemCpyOpt) can emit memcpy / memset for these address