similar to: Question about Alias Analysis with restrict keyword

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, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

Am Di., 17. März 2020 um 16:56 Uhr schrieb Chawla, Pankaj via llvm-dev <llvm-dev at lists.llvm.org>: > All I am expecting from DA is a direction vector containing (*). There seems to be a bug in DI, see Felipe's answer. > I think the main problem is that currently there is no exact way DA can query AliasAnalysis in a ‘conservatively correct’ manner. > > Using UnknownSize

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Nuno and Arnold: > > Thank you all for the input. > > Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. > A clique is statically or dynamically allocated type-free stretch of memory. A "clique" > 1) is maximal in the sense

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

Hi, Nuno and Arnold: Thank you all for the input. Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. A clique is statically or dynamically allocated type-free stretch of memory. A "clique" 1) is maximal in the sense that a clique dose not have any enclosing data structure that can completely cover or, partially

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

On 2/27/13 11:21 AM, Arnold Schwaighofer wrote: > On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> Hi, Nuno and Arnold: >> >> Thank you all for the input. >> >> Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. >> A clique is statically or dynamically allocated

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

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

Am Mi., 18. März 2020 um 18:15 Uhr schrieb Chawla, Pankaj <pankaj.chawla at intel.com>: > > >> DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another method added to AA that gives additional guarantees. Please see the bug report for details. > > Thanks for updating the bug report but GetUnderlyingObject() doesn't help in this case.

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

Hello, I am building the SPEC 2006 Benchmark with Clang as the compiler. I have written a function pass in LLVM and I am trying to run that for SPEC by invoking the pass in the build options of SPEC. The build options of SPEC are in a *.cfg config file, which allows us to specify the choice of compiler while building SPEC. (https://www.spec.org/cpu2006/Docs/install-guide-unix.html) The pass

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.

Thank you all for your replies. So here seems to be an agreement that the documentation for PartialAlias is incorrect. Daniel: now you got me wondering about MustAlias. This is what the docs say: "The MustAlias response may only be returned if the two memory objects are *guaranteed to always start at exactly the same location*" This statement is regardless of the access sizes. For

Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >