similar to: [InstCombine] Missed optimizations when null check before return statement

Use *last = nullptr; for (Use &U : Src->uses()) last = &U; last->getUser()->dump(); Or any better solution? 2018-04-20 19:19 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Is: > > > 2018-04-20 18:07 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > >> Hello, >> >> Code: https://godbolt.org/g/EG4Wi6

Maybe nicer.. auto i = Src->uses().begin(); std::advance(i, Src->getNumUses() - 1); i->getUser()->dump(); 2018-04-20 19:19 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Use *last = nullptr; > for (Use &U : Src->uses()) > last = &U; > last->getUser()->dump(); > > > Or any better solution? > > 2018-04-20 19:19

Hello, Code: https://godbolt.org/g/EG4Wi6 unsigned fff3(void) { char buf[10] = ""; return strlen(buf); } Since we are memset-ing before strlen call, we could replace strlen with just 0. Has LLVM any API to get "last instruction before strlen" which modifies strlen argument "buf"? So we can check "yes, it is memset there, replace strlen with zero"

Is: 2018-04-20 18:07 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > Hello, > > Code: https://godbolt.org/g/EG4Wi6 > > unsigned fff3(void) { > char buf[10] = ""; > return strlen(buf); > } > > Since we are memset-ing before strlen call, we could replace strlen with > just 0. > > Has LLVM any API to get "last

Hello, Here is simple test code: https://godbolt.org/g/mjAUpu LLVM generally assumes that malloc never fails. But I dont understand difference between these two example functions - and why null check was not removed in f1, since in f2 it was removed. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 4/13/2018 6:39 PM, Dávid Bolvanský via llvm-dev wrote: > > Here is simple test code: > https://godbolt.org/g/mjAUpu > > LLVM generally assumes that malloc never fails. > > But I dont understand difference between these two example functions - > and why null check was not removed in f1, since in f2 it was removed. That's because the return value from malloc is

2018-04-14 7:51 GMT+08:00 Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org>: > On 4/13/2018 6:39 PM, Dávid Bolvanský via llvm-dev wrote: >> >> >> Here is simple test code: >> https://godbolt.org/g/mjAUpu >> >> LLVM generally assumes that malloc never fails. >> >> But I dont understand difference between these two example

> On 4/14/2018 3:09 AM, 陳韋任 wrote: >> 2018-04-14 7:51 GMT+08:00 Krzysztof Parzyszek via llvm-dev >> <llvm-dev at lists.llvm.org>: >>> On 4/13/2018 6:39 PM, Dávid Bolvanský via llvm-dev wrote: >>>> Here is simple test code: >>>> https://godbolt.org/g/mjAUpu >>>> >>>> LLVM generally assumes that malloc never fails.

Hi Dávid, Looks like you can defeat the switch conversion by adding a dummy asm(“”): #define likely(x) __builtin_expect((x),1) // switch like char * b(int e) { if (likely(e == 0)) return "0"; asm(""); if (e == 1) return "1"; else return "f"; } Dave > On May 9, 2018, at 2:33 PM, Dávid Bolvanský via llvm-dev

Thanks, interesting. But a fix needs to be made since branch predictor hints are broken in a valid C++20 code: https://godbolt.org/g/dpSDqd Dňa st 9. 5. 2018, 20:40 David Zarzycki <dave at znu.io> napísal(a): > Hi Dávid, > > Looks like you can defeat the switch conversion by adding a dummy asm(“”): > > #define likely(x) __builtin_expect((x),1) > > // switch like

Hello, #define likely(x) __builtin_expect((x),1) // switch like char * b(int e) { if (likely(e == 0)) return "0"; else if (e == 1) return "1"; else return "f"; } GCC correctly prefers the first case: b(int): mov eax, OFFSET FLAT:.LC0 test edi, edi jne .L7 ret But Clang seems to ignore _builtin_expect hints in this case.

I did https://bugs.llvm.org/show_bug.cgi?id=37368 2018-05-09 20:33 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > I did > > https://bugs.llvm.org/show_bug.cgi?id=37368 > > 2018-05-09 20:29 GMT+02:00 David Zarzycki <dave at znu.io>: > >> I’d wager that the if-else chain is being converted to a "switch >> statement” during an optimization

Hi all, I found some issues during my testing of "loop unrolling" capabilities of LLVM's opt. Seems like LLVM generates slower code with -O3 since it wrongly decides to unroll a simple loop. With option -Os, no loop unrolling, the output looks well. Code:

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

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

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

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'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

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>