search for: memoryloc

Dear llvm contributors, Could you please advise me where objects of MemoryLocation class are created for ‘llvm.memset.*‘ intrinsics? In the Bug 23077 (https://llvm.org/bugs/show_bug.cgi?id=23077) the AliasSetTracker constructs 128 alias sets for 0 pointer values, which contain only unknown instructions. In this case, all unknown instructions, which are added to new alias se...

2015-12-11 23:44 GMT+05:00 Hal Finkel <hfinkel at anl.gov>: > Hi Roman, > > The MemoryLocation objects are involved in findAliasSetForUnknownInst, but none are created there for the memset intrinsic. MemoryLocation objects are only involved for the regular memory accesses being compared to the unknown instruction. See AliasSet::aliasesUnknownInst in lib/Analysis/AliasSetTracker.cpp. &gt...

...hese two pointers are related by the getelementptr 1298     // instruction.  If one pointer is a GEP with a non-zero index of the other 1299     // pointer, we know they cannot alias. 1300 1301     // If both accesses are unknown size, we can't do anything useful here. 1302     if (V1Size == MemoryLocation::UnknownSize && 1303         V2Size == MemoryLocation::UnknownSize) 1304       return MayAlias; 1305 1306     AliasResult R = aliasCheck(UnderlyingV1, MemoryLocation::UnknownSize, 1307                                AAMDNodes(), V2, MemoryLocation::UnknownSize, 1308                  ...

On 11/17/2017 02:01 AM, Hongbin Zheng wrote: > Do you mean a and b are noalias if: > > static int foo(int *a, int *b) { > return a[0] + b[0]; > } > > int bar(int *x) { > return foo(x+1, x); > } > > ? > > To me, because "AA.alias((x+1, MemoryLocation::UnknownSize), > (x, MemoryLocation::UnknownSize)) != NoAlias", so a and b are not noalias. Remember that MemoryLocation::UnknownSize is unknown, but positive. So you need to check both "AA.alias((x+1, MemoryLocation::UnknownSize), (x, MemoryLocation::UnknownSize)) == NoAlias&...

Hi, RFC Im adding 2 new functions to the AliasAnalysis interface: 1) ModRefSameBufferCheck: this function will receive 2 memoryLocation as parameters, and returns true if the parameters are modifying or refering the same buffer or same memory block, false otherwise. 2) getAddressesDistance: the function will recieve 2 memoryLocation, if they are mod/ref-ing the same buffer/memory block, the function will return the distance...

What are you querying the alias analysis on in the above example - between the load and store? How are you creating your MemoryLocation for those too? On Fri, Nov 15, 2019 at 6:03 AM Venkataramanan Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can someone please clarify me on this? > > > > On Wed, 13 Nov 2019 at 22:25, Venkataramanan Kumar < > venkataramanan.kumar.llvm at gmail.com>...

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/20...

Hi all, i hope to get the MemoryLocation for argument %1 in a CallInst like "call void @function(i32* %1)", and i found an interface "getForArgument()" which seems available for this. However, i don't know how to correcly fill the 3rd argument TargetLibraryInfo in my own code and can't find an example in g...

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

...t;> 1) This condition seems very strict and I don't think it's met in a few >> places I found by manual inspection > If I read the definition correctly, at least our Andersens' AA > implementation violates it. > see: > > AliasResult CFLAndersAAResult::alias(const MemoryLocation &LocA, > const MemoryLocation &LocB) { > if (LocA.Ptr == LocB.Ptr) > return LocA.Size == LocB.Size ? MustAlias : PartialAlias; > > > (i.e. the two objects are overlapping here *and* start at the same address). I've ne...

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ý <da...

...After following this rabbit hole a bit, there are a lot of mutually recursive calls, etc, that may or may not do the right thing with vectors of pointers. I can fix *this* particular bug with the attached patch. However, it's mostly papering over stuff. Nothing seems to know what to do with a memorylocation that is a vector of pointers. They all expect memorylocation to be a single pointer location. I would chalk it up to "luck" that this patch fixes the bug. It's pretty clear that MemoryLocation doesn't fit the needs of a lot of stuff anymore (we hacked AA nodes into it, and...

...} ------------------------------------------------------ That IR is still wrongly transformed with this code to ret i32 0 (but there is write between calloc and strlen). Any suggestions? 2018-05-23 0:49 GMT+02:00 Dávid Bolvanský <david.bolvansky at gmail.com>: > 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? :) > > 20...

...le of ideas: (a) Extend the getModRefInfo interface (+getModRefBehavior, +gerArgModRefInfo) to return a pair {ModRefInfo, AliasResult}. The AliasResult can be optional based on an argument e.g.: struct MRI_AR { ModRefInfo MRI, AliasResult AR }; MRI_AR getModRefInfoAlias (LoadInst *LI, MemoryLocation Loc, bool SetAliasResultField); Add wrapper APIs to preserve current calls. e.g.: ModRefInfo getModRefInfo (LoadInst *LI, MemoryLocation Loc) { return getModRefInfoAlias (LI, Loc, false).MRI; } (b) From talking offline with George, introducing a MRI_MustMod in ModRef...

...ole a bit, there are a lot of mutually > recursive calls, etc, that may or may not do the right thing with vectors > of pointers. > I can fix *this* particular bug with the attached patch. > > However, it's mostly papering over stuff. Nothing seems to know what to > do with a memorylocation that is a vector of pointers. They all expect > memorylocation to be a single pointer location. > > I would chalk it up to "luck" that this patch fixes the bug. > > It's pretty clear that MemoryLocation doesn't fit the needs of a lot of > stuff anymore (we h...

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 '@calloc_strlen' LLVMSymbolizer: error reading file: No...

...ferent but memory addresses overlap. IE it seems reasonable to say that a load of 2 MustAlias 1 but a load of 1 PartialAlias 2. It also seems reasonable to declare these both PartialAlias. In any case, our current implementation, from what i remember (i didn't trace *every* path), says: if MemoryLocations are same size: may if no idea must if the same partial if we can prove overlap If MemoryLocations are different sizes: may if no idea partial if overlap never must On Fri, Jul 14, 2017 at 1:06 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: On 07/14/2017 03:00 PM...

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* >...

On 11/17/2017 01:49 AM, Hongbin Zheng wrote: > Could you elaborate "Note that, without further analysis of the uses > of the potentially-noalias pointers, you can do this only ..."? > Why the uses, instead of the def, of pointer matter? Both matter. static int foo(int *a, int *b) { return a[0] + b[1]; } int bar(int *x) { return foo(x+1, x); } You can't mark a and

...pointers. > > > > > > > > > > I can fix *this* particular bug with the attached patch. > > > > > > > > > > However, it's mostly papering over stuff. Nothing seems to know > > > > what > > > > to do with a memorylocation that is a vector of pointers. They > > > > all > > > > expect memorylocation to be a single pointer location. > > > > > > > > > > I would chalk it up to "luck" that this patch fixes the bug. > > > > > > &...