similar to: Review request: SimplifyLibcalls - Replace locked IO with unlocked IO

Hello, Please check this patch: https://reviews.llvm.org/D45736 as Eli noted, other opinions are highly welcomed.. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180509/c2eb9888/attachment.html>

It's probably worth going into a little more detail... a lot of people read llvmdev, and most of them won't click the link or follow the whole discussion. The transform in question is replacing "fputc(...)" with "fputc_unlocked(...)" when we can prove the FILE* doesn't escape. The question is whether it's safe for the compiler to emit a call to

On 05/08/2018 07:13 PM, Friedman, Eli via llvm-dev wrote: > It's probably worth going into a little more detail... a lot of people > read llvmdev, and most of them won't click the link or follow the > whole discussion. > > The transform in question is replacing "fputc(...)" with > "fputc_unlocked(...)" when we can prove the FILE* doesn't escape. 

Hi, LLVM optimizer seems to leave "call exit" instruction in "main" function but it could be replaced by a return instruction. Any reason why leave it as is or this simple optimization could be implemented e.g. in SimplifyLibCalls? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

You might want to look more carefully at how you're constructing the MemoryLocation.   The first argument is a pointer, and the second argument is the number of bytes pointed to by that pointer (or MemoryLocation::UnknownSize if the number of bytes accessed isn't known). More generally, copy-pasting code you don't understand isn't a good idea. -Eli On 5/22/2018 4:02 PM, Dávid

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

Yeah, sorry for that. Better "It compiles ok (but maybe incorrect code)", not "It works" as I wrote. 2018-05-23 1:08 GMT+02:00 Friedman, Eli <efriedma at codeaurora.org>: > You might want to look more carefully at how you're constructing the > MemoryLocation. The first argument is a pointer, and the second argument > is the number of bytes pointed to by

IR: define i32 @calloc_strlen_write_between() { %call = tail call noalias i8* @calloc(i32 10, i32 1) store i8 97, i8* %call, align 1 %call1 = tail call i32 @strlen(i8* %call) ret i32 %call1 } static bool eliminateStrlen(CallInst *CI, BasicBlock::iterator &BBI, AliasAnalysis *AA, MemoryDependenceResults *MD, const DataLayout &DL, const TargetLibraryInfo *TLI,

It works with MemoryLocation MemoryLocation::get(const CallInst *CI) { AAMDNodes AATags; CI->getAAMetadata(AATags); const auto &DL = CI->getModule()->getDataLayout(); return MemoryLocation(CI, DL.getTypeStoreSize(CI->getType()), AATags); } Is it fine? :) 2018-05-22 23:56 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Looks like there are many overloads

Looks like there are many overloads for "get". http://llvm.org/doxygen/MemoryLocation_8cpp_source.html But nothing for CallInst. Any suggestions how to do a proper one? I will look at it too. 2018-05-22 23:34 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Full stack trace: > > opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* >

* 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

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

Full stack trace: opt: /home/xbolva00/LLVM/llvm/include/llvm/ADT/Optional.h:176: T* llvm::Optional<T>::getPointer() [with T = llvm::MemoryLocation]: Assertion `Storage.hasVal' failed. Stack dump: 0. Program arguments: opt aaa.ll -dse -S 1. Running pass 'Function Pass Manager' on module 'aaa.ll'. 2. Running pass 'Dead Store Elimination' on function

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

On 05/22/2018 11:59 AM, Dávid Bolvanský wrote: > It could save useless parsing in s/f/printf during runtime. Sure. But it is not clear that matters. printf is expensive anyway. Maybe this matters more for snprintf? Have you benchmarked this? > > E.g. for heavy "fprint"ing code like fprintf(f, "%s: %s", TAG, msg); I > think it could be quite useful.  > After

It could save useless parsing in s/f/printf during runtime. E.g. for heavy "fprint"ing code like fprintf(f, "%s: %s", TAG, msg); I think it could be quite useful. After this transformation we would get fprintf(f, "ABC: %s", msg); --> We could save one push/mov instruction + less parsing in printf every time we call it. We would just replace string constant

"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)

On Aug 1, 2012, at 9:49 PM, Meador Inge <meadori at codesourcery.com> wrote: > Hi All, > > I finally got around to cleaning up my proposal to merge `SimplifyLibCalls` > into `InstCombiner`. There is still an open question or two and I am sure > there are parts that could be better specified, but this is good enough to > discuss. Feedback is most welcome. Fantastic,

Thanks. Yes, to substitute only some of the arguments. Formatting used by printf depends on the locale but only for double, float types I think - yes, I would not place double/float constants into the format string. Why? To reduce number of constants (some of them could be merged into the format string) and number of args when calling printf/fprintf/sprintf, etc.. 2018-05-22 16:22 GMT+02:00 Hal

On Tue, May 22, 2018 at 12:59 PM, Dávid Bolvanský via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It could save useless parsing in s/f/printf during runtime. > A mix of calls to puts and calls to printf with format strings containing just a conversion specifier can help towards such a goal without mutating constants beyond the format string. > > E.g. for heavy