similar to: Malloc null checks, why sometimes are moved and sometimes not?

Displaying 20 results from an estimated 7000 matches similar to: "Malloc null checks, why sometimes are moved and sometimes not?"

2018 Apr 13
0
Malloc null checks, why sometimes are moved and sometimes not?
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 Apr 14
1
Malloc null checks, why sometimes are moved and sometimes not?
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
2018 Apr 18
1
Malloc null checks, why sometimes are moved, and sometimes not?
> 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.
2018 Apr 20
2
Missed strlen optimizations
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
2018 May 09
3
Ignored branch predictor hints
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.
2018 May 09
2
Ignored branch predictor hints
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
2018 Apr 20
0
Missed strlen optimizations
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
2018 May 09
0
Ignored branch predictor hints
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
2018 Apr 20
2
Missed strlen optimizations
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"
2018 Apr 20
0
Missed strlen optimizations
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
2018 May 22
2
DSE: Remove useless stores between malloc & memset
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
2018 May 22
2
DSE: Remove useless stores between malloc & memset
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
2018 May 22
0
DSE: Remove useless stores between malloc & memset
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
2018 May 22
2
DSE: Remove useless stores between malloc & memset
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
2018 May 22
0
DSE: Remove useless stores between malloc & memset
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,
2018 May 22
2
DSE: Remove useless stores between malloc & memset
* 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
2018 May 22
0
DSE: Remove useless stores between malloc & memset
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* >
2018 May 17
3
DSE: Remove useless stores between malloc & memset
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
2018 May 21
2
DSE: Remove useless stores between malloc & memset
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
2018 May 22
0
DSE: Remove useless stores between malloc & memset
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