search for: memorylocations

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 sets in the

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.

Hello All, I have met a case with restrict keyword and I have a question about it. Let's look at a simple example. char buf[4]; void test(char *restrict a, char *restrict b, int count) {   for (unsigned i = 0; i < count; i++) {     *a = *b;     a++;     b++;     buf[i] = i;   } } I think there are no aliasing among pointers such as 'a', 'b' and 'buf'

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.

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

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

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

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 google. Does anybody know how to do it? Or some other advice for

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

On 07/14/2017 03:00 PM, Davide Italiano via llvm-dev wrote: > On Fri, Jul 14, 2017 at 12:50 PM, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I going through the alias analysis documentation >> (http://llvm.org/docs/AliasAnalysis.html) and noticed the following in the >> definition of PartialAlias: >> " >> The

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

...e needs of a lot of stuff anymore (we hacked AA nodes into it, and lots of stuff now tries to figure out the invariantess of the locations, blah blah blah), but it seems like a big job to figure out what to replace it with that will work for these cases. (I'm pretty positive if we just make it MemoryLocations, and have everything loop over the locations, the compiler will get a lot larger and a lot slower) On Mon, Aug 29, 2016 at 9:10 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > it would also, for that matter, say the same about an array of pointers. > > It's not clear to me...

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,

Hi, This came up in https://reviews.llvm.org/D38569, and I'd like some input on what's the best way to get alias and mod-ref info without having two alias calls. A couple 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 {

...f anymore (we hacked AA nodes into it, and lots of stuff now tries to > figure out the invariantess of the locations, blah blah blah), but it seems > like a big job to figure out what to replace it with that will work for > these cases. > > (I'm pretty positive if we just make it MemoryLocations, and have > everything loop over the locations, the compiler will get a lot larger and > a lot slower) > > On Mon, Aug 29, 2016 at 9:10 AM, Daniel Berlin <dberlin at dberlin.org> > wrote: > >> it would also, for that matter, say the same about an array of pointers. &gt...

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

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

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

...; > > blah > > > > blah), but it seems like a big job to figure out what to > > > > replace > > > > it > > > > with that will work for these cases. > > > > > > > > > > (I'm pretty positive if we just make it MemoryLocations, and > > > > have > > > > everything loop over the locations, the compiler will get a lot > > > > larger and a lot slower) > > > > > > > > > > On Mon, Aug 29, 2016 at 9:10 AM, Daniel Berlin < > > > > dberlin at dbe...