search for: vaivaswatha

...idn't realise that adding GlobalsAA* after* SLPVectorizer could help. Thanks for this tip. >There is something fishy. Do you have a test case that reproduce with llvm-lto? I'm currently looking at a proprietary benchmark. I'll try to extract out a simple test case and send it. - Vaivaswatha On Fri, Dec 4, 2015 at 12:00 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 3, 2015, at 8:29 AM, Vaivaswatha Nagaraj <vn at compilertree.com> > wrote: > > Hi Mehdi, > > Thank you for the response. > > I'm actually on an LTO setup and was re...

...has GlobalsAA available during GVN, rest of them do not as SLP vectorizer run on that function invalidates GlobalsAA which is a module pass. Is there a way to force re-computation of a particular analysis? As a side note, I didn't have this problem on release_37. Thanks a lot. Regards, - Vaivaswatha On Thu, Dec 3, 2015 at 3:02 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Vaivaswatha, > > GlobalsAA is not an immutable pass because it needs to cache queries to > avoid them being unusably slow. It therefore relies on passes explicitly > preserving it. Most of t...

...e analysis, rest of the functions do not have it available. Both LICM and GVN face the same issue. Surprisingly I didn't see this issue on release37. In fact, on an LTO setup, more LICMs happen on release37 than on the latest SVN, for many of the benchmarks, just because of this. Thanks, - Vaivaswatha On Thu, Dec 3, 2015 at 9:21 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 3, 2015, at 4:21 AM, Vaivaswatha Nagaraj via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Thank you both for the inputs. I've created a patch for the same, please > re...

...at the way pass manager works, it looks like it wasn't of much use. Since GlobalsAA is a ModulePass, and FunctionPasses that are scheduled even later are run first, those FunctionPasses that invalidate it do so for good. I do not know if there is some other way to force it though. Thanks, - Vaivaswatha On Thu, Dec 3, 2015 at 4:53 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "James Molloy" <james at jamesmolloy.co.uk> > > Cc: &q...

...I'm currently working on a program where having these attributes could help GlobalsAA give significantly more precise results. Considering that this info is propagated to the caller, its caller and so on, this may have a wider impact than the program I'm currently looking at. Thanks, - Vaivaswatha On Thu, Dec 3, 2015 at 2:57 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Vaivaswatha, > > I think not adding readnone/readonly to malloc/realloc is correct. > malloc/free hooks can be added to most implementations (for leak checking > and so on), so calling mallo...

...call to AAResultsWrapperPass::runOnFunction() before GVN does not add GlobalsAAWrapperPass due to unavailability. This leads to the alias queries from GVN not having any globals mod-ref info. Is this a known issue? and is there any way to have globals mod-ref info available for GVN? Thanks, - Vaivaswatha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151202/8a2a7cbb/attachment.html>

...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 compilertree.com> >wrote: > >> 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 Mol...

...dd-recurrence for "j". I would've expected a similar computation for the first case too, something like {0,+,%0}<nsw><%for.cond1> Where %0 would be the LoadInst for "incr".  Is this a bug or is there something more involved that causes the deficiency? Thanks,- Vaivaswatha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141128/c59536db/attachment.html>

...e of malloc/realloc in a function needs to invalidate all mod-ref info gathered for that function so far. Please let me know if the question is not clear. I'll try to extract out a simple test case from the program I'm looking at and post it, so as to have a concrete example. Thanks, - Vaivaswatha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151202/058320db/attachment.html>

...ions 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 versions of your C library (not > entirely crazy - i...

...in the compiler) Inaccessible state here refers to any global that is not visible to the program under compilation. The key idea (behind the new attribute) is to convey that these external functions do things inside that the compiler cannot know about, and hence deal with them conservatively. - Vaivaswatha On Fri, Dec 4, 2015 at 9:51 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 4, 2015, at 8:09 AM, Vaivaswatha Nagaraj <vn at compilertree.com> > wrote: > > >what is a non-public state that no-one but you can access? (I’d call that > private). > mall...

> 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 lists.llvm.org> >> Sent: Friday, December 4, 2015 12:28:03 PM >>...

>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 wish. > "HasInaccessibleState" is in fact a no-op because it implies nothing about > the *accessible* sta...

...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 and >check >the format string for %n). > >James > >On Fri, 4 Dec 2015 at 17:53 Vaivaswatha Nagaraj via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> >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 m...

...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, Vaivaswatha Nagaraj <vn at compilertree.com> > wrote: > > >is this "internal state” supposed to be private to the function? > It could be private or...

...ion, both semantically same. Scalar Evolution is unable to determine the exit value of the second loop, leading to the vectorizer failing to vectorize. It seemed to me that this is due to ScalarEvolution::SimplifyICmpOperands failing to canonicalize the corresponding ICMP_ULE instruction. Thanks, - Vaivaswatha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150422/41a73399/attachment.html>

+thread-sanitizer mailing list On Mon, Sep 7, 2015 at 6:41 PM, Vaivaswatha Nagaraj <vn at compilertree.com> wrote: > Hi, > > I am interested in understand the compiler-rt thread sanitizer tool and have > recently started experimenting with it. In particular, I'm interested in the > deadlock detector. > > I see that deadlock detection current...

...(as I understand it): GlobalAA should be able to figure out that calls to malloc/free don't touch global variables visible to the optimizer. How do we address this problem? Yes, this is the primary concern. Most libc functions (including printf, malloc, free) fall into the same category. - Vaivaswatha On Fri, Dec 4, 2015 at 11:12 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> > &gt...

...xamples, currently these optimizations are not happening anyway (from what I understand). The issue is that, after malloc/free are tagged with "ReadNone", such transforms may happen. Hence to prevent that, the additional flag denoting that these functions maintain an internal state. - Vaivaswatha On Fri, Dec 4, 2015 at 12:20 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > On Dec 3, 2015, at 10:33 PM, Vaivaswatha Nagaraj via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > This email is in continuation to the mail thread > http:...

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 attributes > along the call graph. If the name is all that needs closure, I think I can &...