similar to: [LLVMdev] AliasAnalysis Documentation Ambiguity

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

What do you think of this patch? I have added a check for the case I mentioned in the previous email as well as a similar situation I discovered later. Tom ----- Original Message ----- From: "Dan Gohman" <gohman at apple.com> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent:

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,

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

Does any real code benefit from dead code eliminating read-only functions? Tom ----- Original Message ----- From: "Reid Kleckner" <rnk at mit.edu> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev]

Hi, I saw that Nick Lewycky removed the LLVM portable hash_map and hash_sets. My research group was relying on those classes. What replaces hash_map and hash_set? The LLVM implementation was very convenient as there is no equivalent in STL, and Microsoft's implementation had a different name, as does the C++ 0X implementation. Thanks. Tom Jablin

Hi, Is this the right mailing list for sending in diffs by irregular contributers? Should I send diffs directly to the code owner instead? Tom ----- Original Message ----- From: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, September 11, 2008 1:55:09 PM GMT -05:00 US/Canada Eastern

Hi, The call target pass in the poolalloc suite yields an incorrect output for the following short test program: #include <stdio.h> struct OP { void (*func)(struct OP*); }; void bar(struct OP *op); void foo(struct OP *op) { printf("Foo\n"); op->func = bar; } void bar(struct OP *op) { printf("Bar\n"); op->func = foo; } int main(int argc, char **argv)

Hi Hisham, Most likely the basic blocks are the headers of two different loops. Try running viewCFG() on the function in question to see if this is the case. Tom ----- Original Message ----- From: "Hisham Chowdhury" <hisham_chow at yahoo.com> To: llvmdev at cs.uiuc.edu Sent: Wednesday, June 16, 2010 7:22:00 PM GMT -05:00 US/Canada Eastern Subject: [LLVMdev] Loopinfo Analysis

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

Hello, I have a question regrading the analysis pass that generates loop info from an .ll code. My previous understanding was there will be just one loop header(in the loop info) for a particular loop. But, when i use isLoopHeader() member function from the loop info class I get 'true' return value for two different basic blocks. Note both basic blocks are loop conditional block(break

Thanks. I do not have commit privilege. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, December 8, 2008 5:39:33 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Looks good. Do you have commit privilege? Evan On Nov 22, 2008, at

On Thu, Sep 25, 2008 at 5:04 PM, Thomas B. Jablin <tjablin at cs.princeton.edu> wrote: > Hi, > The call target pass in the poolalloc suite yields an incorrect output for the following short test program: The DSA results are now (r56847) correct for this test case. The call is marked incomplete. Doing better is actually a pathological case in DSA which is hard to fix without

----- "Evan Cheng" <evan.cheng at apple.com> wrote: > On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > > > Evan, > > So, if I understand you correctly, the design you have in mind is > > to: create a PassManager, pass it to the JIT on construction, and > > modify runJITOnFunction to run the second PassManager on the > > Function

Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write

Just want to test out the LLVM's AliasAnalysis::getModRefInfo API. The input C code is very simple: void foo(int *a, int *b) { for(int i=0; i<10; i++) b[i] = a[i]*a[i]; } int main() { int a[10]; int b[10]; for(int i=0; i<10; i++) a[i] = i; foo(a,b); return 0; } Obviously, for "foo", it only reads from array "a" and only writes to array

Something must be wrong, more probable on my side. So the C source code is unchanged, I just did another experiment to first extract all the GEPs in the code, and call AliasAnalysis::alias on each pair of GEPs. Here is the code: AliasAnalysis &AA = getAnalysis<AliasAnalysis>(); TargetData &TD = getAnalysis<TargetData>(); for (Module::iterator it = M.begin();