search for: doesnotaccessmemori

<<< I may misunderstand, but it seems to me that this solves only query for aliasing with a pointer known to be pointing only to globals defined in the current compilation unit. For any pointer which "may point somewhere else”, you won’t be able to resolve the non-aliasing with the “internal state” for malloc/free, right? To take the original example in this thread: int *x =

Hello LLVM devs, I'm trying to write my own alias analysis that only contributes information to the getModRefBehavior query, and should be in its own library loadable by opt. However, even though my pass is run (and executed immediately before the client pass that is calling AA.doesNotAccessMemory(F)), the queries never reach my implementation. What am I missing? Thanks in advance,

Hi, This email is in continuation to the mail thread http://lists.llvm.org/pipermail/llvm-dev/2015-December/092996.html, to propose a new function attribute that can convey that a function maintains state, but this state is inaccessible to the rest of the program under compilation. Such a flag could be added to most libc/system calls such as printf/malloc/free. (libc and system calls do

>is this "internal state” supposed to be private to the function? It could be private or not. Hence the name "inaccessible", to mean that the program under compilation has no access to the state. So while printf and malloc (for example) could share state in libc, the program under compilation cannot access this state. >how this flag would prevent the last “optimization”

Hello, Is there a analysis pass which calculates the ModRefBehaviours OnlyReadsPointerArguments and OnlyAccessesPointerArguments? I tried to find one but so far I only saw that different AA's return OnlyReadsMemory and DoesNotAccessMemory if the readonly and readnone attributes are set. Best regards and thanks in advance, Johannes -- Johannes Doerfert Researcher / PhD Student

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Joseph Tremoulet" <jotrem at microsoft.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 1:28:05 PM > Subject: Re: [llvm-dev] RFC: New function attribute

Hi, GlobalsAA, during propagation of mod-ref behavior in the call graph, looks at library functions (in GlobalsAAResult::AnalyzeCallGraph: F->isDeclaration() check), for attributes, and if the function does not have the onlyReadsMemory attribute set, forgets it. I noticed that library functions such as malloc/realloc do not have the attributes doesNotAccessMemory or onlyReadsMemory

>but is there or is there not accessible, visible state, Wouldn't ReadNone and/or ReadOnly cover that? If ReadNone is set, it means it doesn't access any of the visible (accessible) states. - Vaivaswatha On Fri, Dec 4, 2015 at 3:17 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I don't think the attribute as is is strong enough to do what you

Julian Oppermann wrote: > Hello LLVM devs, > > I'm trying to write my own alias analysis that only contributes > information to the getModRefBehavior query, and should be in its own > library loadable by opt. > > However, even though my pass is run (and executed immediately before the > client pass that is calling AA.doesNotAccessMemory(F)), the queries > never reach

>what is a non-public state that no-one but you can access? (I’d call that private). malloc and free could both use global variables that are defined in libc, but are inaccessible to the program under compilation. >if you’re attribute is saying they have some internal state, then malloc() cannot access the state of free() and vice versa. Which is why it would be preferable to call it

----- Original Message ----- > From: "Joseph Tremoulet" <jotrem at microsoft.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Mehdi Amini" <mehdi.amini at apple.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 3:35:38 PM > Subject: RE: [llvm-dev] RFC: New function attribute

From: Villmow, Micah Sent: Tuesday, November 06, 2012 1:37 PM To: 'llvm-dev at cs.uiuc.edu' Cc: Guo, Xiaoyi Subject: Bug in SelectionDAG visitTargetIntrinsic We ran into a problem where specifying IntrNoMem was causing our instruction selection to fail with target specific intrinsics. After looking into the code and ISel debug it looks like tablegen and SelectionDAG are using different

void SelectionDAGBuilder::visitTargetIntrinsic(const CallInst &I, - unsigned Intrinsic) { - bool HasChain = !I.doesNotAccessMemory(); - bool OnlyLoad = HasChain && I.onlyReadsMemory(); + unsigned Intrinsic) { + // Info is set by getTgtMemInstrinsic + TargetLowering::IntrinsicInfo Info; + bool

Tks Tom, That is my confusing part. How can I make it to "access memory” so it will HasChain? Is there any flag set like in typeProfile, Node, instructions? myLoad, mayStore, SDNPHasChain? -kevin On Jul 18, 2014, at 4:26 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Jul 18, 2014 at 04:15:45PM -0400, kewuzhang wrote: >> sure! >> >> class

Hi James, Thank you for the response. I understand the concern about malloc/free hooks. Could we detect that a program has setup malloc hooks (assuming we're in a whole program compilation) and make assumptions (such as onlyAccessesArgMem()) when the program hasn't setup malloc hooks? Using a command line flag could be one option too. I'm currently working on a program where having

>there would be two disjoint global states In some sense yes, but technically not disjoint. Functions marked with this attribute should still be able to access the globals within the program under compilation, if its not marked with ReadNone. >If malloc and free can both use global variables (there is no notion of library in the compiler) Inaccessible state here refers to any global that is

----- Original Message ----- > From: "Vaivaswatha Nagaraj" <vn at compilertree.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Joseph Tremoulet" <jotrem at microsoft.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Sunday, December 13, 2015 9:50:25 PM > Subject: Re: [llvm-dev] RFC: New function attribute

Hi, If these are the options, I'm also in favour of approach B. Approach A redefines ReadNone, which I don't think is acceptable. James On Mon, 14 Dec 2015 at 08:15 Vaivaswatha Nagaraj via llvm-dev < llvm-dev at lists.llvm.org> wrote: > >I am in favor of approach B (although perhaps with different names). > Just to clarify, this does not requires any propagation of

Vaivaswatha Nagaraj via llvm-dev wrote: > >I'm against adding this as a "subtractive" attribute. We need to add these as new attributes, not as an attribute that > makes readonly a little less read only. I believe we're in agreement on this point. > Just to make sure I understood right, below are the things that need to be done: > (Approach A) > 1. We

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >