similar to: RFC: New function attribute HasInaccessibleState

>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”

>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

>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

>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

>What if you had bitcode versions of your C library Then the definitions for these functions would be available. Would we still set function attributes to these functions in FunctionAttrs.cpp if their definitions were available? >This also seems a bit tailored to malloc/free, and can't work for user-defined allocation functions I don't think so. For example, printf would have the

----- 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

----- 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

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: "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

<<< 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 =

Sigh... let me try that last part again: Maybe GlobalsAA and/or a GlobalsAA-centric attribution pass could partition writes as: 1. Stores to local allocas 2. Stores through pointer parameters 3. Stores to globals defined in this compilation unit 4. Other Attributing functions with attributes: readonly: only writes of type 1 argmemonly: only writes of type 1/2 almost-readonly: only

----- 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 > >

We used a similar thing in the phx compiler. We called it "ExternalMemoryTag". It was a name for "all the program state that doesn't have another name", and in phx (unlike LLVM) it was easy to define what "has another name" meant since we kept an explicit universe of names in our alias metadata. The inferences were flipped the other way, though; being able to

> On Dec 4, 2015, at 10:33 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Vaivaswatha Nagaraj" <vn at compilertree.com> >> To: "James Molloy" <james at jamesmolloy.co.uk>, "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM Dev" <llvm-dev at

that would be an escaping global, and as far as I know is handled separately in GlobalsAA (AnalyzeUsesOfPointer checks if a global is used as operand to a function) On December 4, 2015 11:47:20 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote: >It is if one of the operands is or can alias a global ? >On Fri, 4 Dec 2015 at 18:16, Vaivaswatha Nagaraj <vn at

>> In the case of user-defined allocation functions, the definitions for those functions are available >Are they? probably not unless you're in an LTO build. Yes, I'm assuming an LTO build. >Printf() is a very nasty one because it can actually affect a lot of state. The %n modifier can cause an argument to be written to. hence it would have HasInaccessibleState and ArgMemOnly

writing into operands is not the same as writing to globals right? I added printf in the same category since we were discussing writing to globals. On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote: >Hi, > >I just want to reiterate: printf and friends do *not* fall into this >category as they can write to their operands (unless you parse

I'd like to suggest a different direction which should accomplish similar ends. I think it would make sense to introduce an attribute: csecandidate. If we see a call-site "X" marked as csecandidate, it would imply that it can be replaced with any other call-site "Y" with the same arguments which dominate the call-site at "X". However, there are some cases that

>Most of the time you don't have the entire call graph information. Imagine that you are developing a module that is a part of a larger project. I now understand the concern. It looks to me that we will need to set the flag by default to all functions whose definitions aren't available (external), and then propagate from there on. I don't see any optimizations being inhibited by