search for: isnoaliascall

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 need the function to do in its sole caller. Thinking about what it does without a specific caller in mind, I might think of "noaliasAtFunctionEntry", as it...

...;Argument>(O2) && isNoAliasArgument(O1))) + return NoAlias; Fold this into the logic right above it: // Arguments can't alias with local allocations or noalias calls // in the same function. if (((isa<Argument>(O1) && (isa<AllocaInst>(O2) || isNoAliasCall(O2))) || (isa<Argument>(O2) && (isa<AllocaInst>(O1) || isNoAliasCall(O1))))) return NoAlias; by factoring out the combined tests "isa<AllocaInst>(V) || isNoAliasCall(V) || isNoAliasArgument(V)" into a function. +/// isNoAliasArgument - Return...

...tional ones: GlobalValues which are not GlobalAliases, and byval arguments. Unfortunately, a check of Argument vs. IsIdentifiedObject is too broad, because an argument (which is not noalias) can alias a GlobalValue. Regarding the namespace - I just thought I should keep isNoAliasArgument close to isNoAliasCall. I'll move it to BasicAliasAnalysis if you think that's a better idea. -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Monday, May 27, 2013 13:54 To: Kuperstein, Michael M Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Mixing noalias and regular argumen...

...and byval arguments. Okay. > Unfortunately, a check of Argument vs. IsIdentifiedObject is too broad, because an argument (which is not noalias) can alias a GlobalValue. Right. IsIdentifiedFunctionLocal? :) > Regarding the namespace - I just thought I should keep isNoAliasArgument close to isNoAliasCall. > I'll move it to BasicAliasAnalysis if you think that's a better idea. I generally avoid adding things to llvm:: when I can avoid it, but I don't care a whole lot. If you think it's a utility that could be used more generally, llvm:: is fine. Nick > > -----Original M...

...t;Argument>(O2) && isNoAliasArgument(O1))) + return NoAlias; Fold this into the logic right above it: // Arguments can't alias with local allocations or noalias calls // in the same function. if (((isa<Argument>(O1) && (isa<AllocaInst>(O2) || isNoAliasCall(O2))) || (isa<Argument>(O2) && (isa<AllocaInst>(O1) || isNoAliasCall(O1))))) return NoAlias; by factoring out the combined tests "isa<AllocaInst>(V) || isNoAliasCall(V) || isNoAliasArgument(V)" into a function. +/// isNoAliasArgument - Return t...

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

...cific alias analysis implementations. This implies that alias can run on ANY two Values without restrictions. However, line 696 of BasicAliasAnalysis reads: // Arguments can't alias with local allocations or noalias calls. if ((isa<Argument>(O1) && (isa<AllocaInst>(O2) || isNoAliasCall(O2))) || (isa<Argument>(O2) && (isa<AllocaInst>(O1) || isNoAliasCall(O1)))) return NoAlias; This reasoning is only valid if the Argument and the AllocaInst or NoAliasCall in question are part of the same function. Here is an example: void foo(int *bar) { } void baz(void...

Hello, 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 <http://en.cppreference.com/w/c/memory/realloc> says: "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." Additionally from the C11 standard