similar to: Why is remalloc not marked as noalias?

On 26 Dec 2017, at 10:13, Bhatu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference says: > "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was

On 01/08/2018 04:40 AM, David Chisnall via llvm-dev wrote: > On 26 Dec 2017, at 10:13, Bhatu via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference says: >> "The original pointer ptr is invalidated and any access

Kuperstein, Michael M wrote: > Ping? Pong! Sorry for the slow review, I had this patch starred but hadn't got around to it. Yes, the rationale and implementation are correct. > (Is there a code owner for AA, btw?) (It falls back on the more general code owner who is Chris Lattner in this case, "Everything not covered by someone else".) +/// isNoAliasArgument - Return true

Kuperstein, Michael M wrote: > Thanks Nick! > > Can you just check sanity before I commit? > (Or suggest a better name for the function...) Sure! +static bool canNotAliasDiffArgument(const Value *V) +{ + return (isa<AllocaInst>(V) || isNoAliasCall(V) || isNoAliasArgument(V)); +} Extra parens? The name "canNotAliasDiffArgument" works, but it's named for what we

Thanks Nick! Can you just check sanity before I commit? (Or suggest a better name for the function...) -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Sunday, May 26, 2013 09:54 To: Kuperstein, Michael M Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Mixing noalias and regular arguments Kuperstein, Michael M wrote: > Ping? Pong! Sorry for the slow review,

Regarding the name, I'm not sure noaliasAtFunctionEntry makes sense, for two reasons: a) The pointer involved may not be defined at entry. b) We already have something which is similar in spirit - IsIdentifiedObject. That covers the 3 cases I have in the new function, but also two additional ones: GlobalValues which are not GlobalAliases, and byval arguments. Unfortunately, a check of

Kuperstein, Michael M wrote: > Regarding the name, I'm not sure noaliasAtFunctionEntry makes sense, for two reasons: > a) The pointer involved may not be defined at entry. Right, I thought of that too. > b) We already have something which is similar in spirit - IsIdentifiedObject. That covers the 3 cases I have in the new function, but also two additional ones: GlobalValues which

Ping? (Is there a code owner for AA, btw?) From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kuperstein, Michael M Sent: Tuesday, May 21, 2013 18:23 To: LLVMdev at cs.uiuc.edu Cc: Raoux, Thomas F Subject: [LLVMdev] Mixing noalias and regular arguments Hi all, I'm trying to understand the semantics of noalias arguments, and I'm not entirely sure I

Hi all, I'm trying to understand the semantics of noalias arguments, and I'm not entirely sure I got it correctly. To the best of my understanding, if an argument is declared noalias, "This indicates that pointer values based on the argument do not alias pointer values which are not based on it" implies, among other things, that it cannot alias any other argument, even if that

Hi Kevin, On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote: > So only "non-freed" malloc pointers are No-Alias which makes it > flow-sensitive. There is no reason why malloc couldn't return previously > freed location. Yes. Talking to Nick Lewycky on IRC, I figured out a shorter way of saying what I wanted to say.  We know that programs like this

The corresponding line does not exist, and it is in fact, wrong :) C11 says nothing like that. C++14 says: "The lifetime of an object of type T begins when: — storage with the proper alignment and size for type T is obtained, and — if the object has non-trivial initialization, its initialization is complete. The lifetime of an object of type T ends when: — if T is a class type with a

Hi all, I think I've spotted a semantic issue with marking @malloc and @realloc as noalias.  Say we have the program: int f() {   int* p0 = malloc(size of(int));   free(p0);   int* p1 = malloc(sizeof(int));   if (!p1) return 20;   int value = 0;   for (int i = 0; i < 1; i++) {     *p1 = 20;     value = *p1;     if (false)  // "false" is obscured in a way the compiler can't

Hi Daniel, On April 11, 2017 at 6:22:34 PM, Daniel Berlin (dberlin at dberlin.org) wrote: > Note: This is a generic problem with any situation where noalias exists but > the pointers are proven equal :) Yes. > TBAA, for example, has the same generic issue, we just drop the tbaa > metadata and declare it okay, even though it would have been UB at the > source level. Yes.  I

On Tue, Apr 11, 2017 at 7:02 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> > It would require semantic changes to llvm ir to fix this to properly >> > express object lifetimes that is compatible with all the random babble >> > standards have written down :) >> > For now, the only sane solution IMHO, is to say that no alias implies

We recently found an issue when using the full restrict implementation developed by Jeroen; it surfaces when compiling an obscure combination of std::valarray and std::indirect_array but I don't want to bore you with all the details. What it boils down to is this basic question about restrict: Given one restrict pointer based on another, should they never alias? As far as I understand the

> > > It seems to me that there are two ways of thinking about this: either the > value of a pointer in IR is richer than its bit sequence, in which case > replacing p1 with p0 in a block predicated by p0 == p1 is an incorrect > transformation if you cannot prove that one pointer was based on the other, > Which would be a non-starter just from the cost of doing so, not to

Thanks, Jeroen, that really helps. A follow-up question, if you don't mind. What if we have code somewhat similar to your example in assign3() but it's in C++ and the pointer derived from x is stored in a class member field: class S { public: S(int *d): data(d) {} int *getData() { return data; } private: int *__restrict__ data; }; void assign4(int *pA, long N) { int

On Tue, Apr 11, 2017 at 3:14 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Kostya, > > On April 11, 2017 at 2:39:44 PM, Kostya Serebryany (kcc at google.com) wrote: > > > ptr0 = malloc(); > > > free(ptr0); > > > ptr1 = malloc(); > > > > > > ptr0 and ptr1 will be NoAlias despite overlapping (there is actually a > >

Given some code: void func (float * restrict a, float *b) { for (int i =0; i < 100; ++i) { a[i] = b[i] + 1; } } float * aa; float * bb; int main() { func(aa, bb); return 0; } produces IR that has the llvm.noalias intrinsic along with the !noalias metadata:for both the load and store, however, AA returns MayAlias, I would expect a NoAlias? This is also an older version of llvm:

Hello, Currently the noalias attribute can be applied on function parameters and return value, or via scoped alias on store. The problem is that there is no easy way to apply the noalias attribute on a pointer that is loaded indirectly (e.g from the field of an aggregate, or from a memory location - though for this you can still use scoped alias, but they are a lot more intrusive) The idea