search for: hasinaccessiblest

...gt; 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 > HasInaccessibleState > >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, belo...

...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 >> > HasInaccessibleState >> >> > >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. >> &gt...

...soft.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 HasInaccessibleState > > Yeah, I'd agree (rewording slightly) that "state which is only > modified by external code" is well-defined (and likely to be in the > "other" bucket of any individual analysis). I do, as other have, > find it odd to redefine readonly and argmemonly i...

...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 define a new a attribute "HasInaccessibleState" to denote "this function might access globals, but none of these > globals can alias with any memory location accessible from the IR being optimized". > 2. Mark malloc/free as (HasInaccessibleState, ReadNone) and printf as (HasInaccessibleState, ArgMemOnly) ... (similarl...

...is 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 access/modify internal variables such as errno). Example attributes (in addition to what are already set): malloc/free: HasInaccessibleState, ReadNone printf: HasInaccessibleState, ArgMemOnly realloc: HasInaccessibleState, ReadOnly (not sure). The intention behind introducing this attribute is to relax the conditions in GlobalsAA as below: (this code is in GlobalsAAResult::AnalyzeCallGraph) if (F->isDeclaration()) {...

...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 wish. > "HasInaccessibleState" is in fact a no-op because it implies nothing about > the *accessible* state. OK, there's inaccessible state but is there or is > there not accessible, visible state, is the question that optimizers need > to ask. > > So I'd rephrase it to something like "HasNoA...

...f 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 access/modify internal > variables such as errno). > > Example attributes (in addition to what are already set): > malloc/free: HasInaccessibleState, ReadNone > printf: HasInaccessibleState, ArgMemOnly > realloc: HasInaccessibleState, ReadOnly (not sure). > > The intention behind introducing this attribute is to relax the conditions > in GlobalsAA as below: > (this code is in GlobalsAAResult::AnalyzeCallGraph) > >...

...and RAUW. On Fri, Dec 4, 2015 at 8:54 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/4/2015 10:48 AM, Vaivaswatha Nagaraj via llvm-dev wrote: > >> This point however reminds me to add, functions that transitively call >> functions with HasInaccessibleState must also have the flag set. >> > > That's in practice impossible to guarantee, both by the compiler and by > the programmer. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > >...

....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 HasInaccessibleState > > > > On Dec 11, 2015, at 11:16 AM, Joseph Tremoulet > > <jotrem at microsoft.com> wrote: > > > > <<< > > I may misunderstand, but it seems to me that this solves only query > > for aliasing with a pointer known to be pointing only to...

...st mail sound right to you? > that'd be redefining the semantics of ReadNone. ReadNone allows elision of a call if its result is unused, @James. That right. Optimizations should hereafter (if the proposed attribute is accepted) be more careful in interpreting ReadNone. If the call also has HasInaccessibleState, it shouldn't remove the call, even if the call takes no arguments or its return value isn't, because it could be modifying some internal state. - Vaivaswatha On Fri, Dec 4, 2015 at 9:10 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 3, 2015, at 11:58 PM,...

...case of user-defined allocation functions, the definitions for those functions are available, and what state they modify is directly visible. I'm not sure I understand how malloc alone would be more powerful. This point however reminds me to add, functions that transitively call functions with HasInaccessibleState must also have the flag set. - Vaivaswatha On Fri, Dec 4, 2015 at 10:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I'm still a bit dubious about this, I don't think it's bombproof. How does > this fit with LTO? What if you had bitcode versio...

...gt; > > that'd be redefining the semantics of ReadNone. ReadNone allows elision > of a call if its result is unused, > @James. That right. Optimizations should hereafter (if the proposed > attribute is accepted) be more careful in interpreting ReadNone. If the > call also has HasInaccessibleState, it shouldn't remove the call, even if > the call takes no arguments or its return value isn't, because it could be > modifying some internal state. > > > - Vaivaswatha > > On Fri, Dec 4, 2015 at 9:10 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > &gt...

...efinitions 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 set, but not ReadNone or ReadOnly set. >Yes. Definitions being available should only *increase* the set of attributes that can be added to them, never decrease. I agree with that. But what I meant was, during a compilation invocation, we either have the definitions available o...

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

...quot; <kparzysz at codeaurora.org> >>>>> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> >>>>> > Sent: Friday, December 4, 2015 11:21:03 AM >>>>> > Subject: Re: [llvm-dev] RFC: New function attribute >>>>> > HasInaccessibleState >>>>> >>>>> > >> 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...

...t; To: "James Molloy" <james at jamesmolloy.co.uk>, "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> >> Sent: Friday, December 4, 2015 12:28:03 PM >> Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState >> >> 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) >> > > More generally, I think this attribute is supposed to mean, "this fu...

...v at lists.llvm.org> > > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> > > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > > Sent: Friday, December 4, 2015 11:21:03 AM > > Subject: Re: [llvm-dev] RFC: New function attribute > > HasInaccessibleState > > > >> 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. > > The concerns ar...

...; To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> >>> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> >>> > Sent: Friday, December 4, 2015 11:21:03 AM >>> > Subject: Re: [llvm-dev] RFC: New function attribute >>> > HasInaccessibleState >>> >>> > >> 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. >>> >>> > Y...

...al Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev Sent: Friday, December 4, 2015 7:33 PM To: Mehdi Amini <mehdi.amini at apple.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState ----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Vaivaswatha Nagaraj" <vn at compilertree.com>, "LLVM Dev" > <llvm-dev at lists.llvm.org> >...

...om: Joseph Tremoulet Sent: Tuesday, December 8, 2015 1:12 PM To: Joseph Tremoulet <jotrem at microsoft.com>; Hal Finkel <hfinkel at anl.gov>; Mehdi Amini <mehdi.amini at apple.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] RFC: New function attribute HasInaccessibleState [sorry for the re-send; fixed a couple critical typos inline] 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 &...