similar to: nls and if statements

I've been trying to figure out how to get the names of the parameter vector variables when inside the function that nlm calls to return the objective function value: knls <- function( theta, eqns, data, fitmethod="OLS", instr=NULL, S=NULL ) { ## print( names( theta ) ) # returns NULL ## get the values of the parameters for( i in 1:length( theta ) )

Dear R programming folks: I'm trying to finish off a package for non-linear simultaneous system estimation and I've been trying to figure out how to get the names of the parameter vector variables when inside the function that nlm calls to return the objective function value: knls <- function( theta, eqns, data, fitmethod="OLS", instr=NULL, S=NULL ) { ## print(

Hello everyone, If you've read through my previous introduction email (http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you can safely ignore this message. The short story is: CFL-AA does not seem to be broken anymore. Please try it out and help us find more bugs / performance issues if switching to it in the future sounds interesting to you. Here are more backgrounds: I

Hi folks, Moving the discussion to llvm.dev. None of the changes we talked earlier help. Find attached the C source code that you can use to reproduce the issue. clang --target=aarch64-linux-gnu -c -mcpu=cortex-a57 -Ofast -fno-math-errno test.c -S -o test.s -mllvm -debug-only=licm LICM hoisting to while.body.lr.ph: %21 = load double** %arrayidx8, align 8, !tbaa !5 LICM hoisting to

(Just to note: the other issue i remember with CFL-AA is that it currently causes performance loss. This is quite common when you increase precision, because things move/change things they couldn't before, and often do so without the natural bounds imprecision provided before :P) On Thu, May 12, 2016 at 12:29 AM, James Molloy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yep,

Inline - George > On Jan 14, 2015, at 10:49 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > >> On Tue, Jan 13, 2015 at 11:26 PM, Nick Lewycky <nlewycky at google.com> wrote: >>> On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote: >>> This is caused by CFLAA returning PartialAlias for a query that BasicAA can

Dear LLVM community, I am a GSoC student this year working on the project of improving alias analysis in LLVM. The proposal initially came from a discussion I had with various devs on the mailing list some time ago [1]. The general goal of this project is to make alias analysis (in particular, cfl-aa) "better", and to be more concrete here is a list of objectives I had in mind: -

Can you send me actual LLVM IR or a preprocessed source from using -E? I don't have a machine handy that has headers that target that arch. On Tue Jan 13 2015 at 4:33:29 PM Daniel Berlin <dberlin at dberlin.org> wrote: > Anything other than noalias or mustalias should be getting passed down the > stack, so either that is not happening or CFL aa is giving better answers > and

On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote: > This is caused by CFLAA returning PartialAlias for a query that BasicAA > can prove is NoAlias. > One of them is wrong. Which one? I'm not sure from your description that this is a chaining issue. PartialAlias doesn't chain and isn't supposed to, it's a final answer just like NoAlias and

Hello everyone, One of Google's summer interns, George Burgess IV, created an implementation of the CFL pointer-aliasing analysis algorithm, and this has now been added to LLVM trunk. Now we should determine whether it is worthwhile adding this to the default optimization pipeline. For ease of testing, I've added the command line option -use-cfl-aa which will cause the CFL analysis to be

On 05/11/2016 05:16 PM, George Burgess IV via llvm-dev wrote: > > After applying the patch on r267335 and bootstrap LLVM/clang with > cfl-aa enabled on its own as well as behind basic-aa on an x86 > machine, I ran test-suite with lit and saw no failed test cases > > Woohoo! This is great news. :D Awesome! > > I'm not sure how closely everyone is reading the intro

Oh, sorry, i didn't rebase it when i changed the fix, you would have had to apply the first on top of the second. Here is one against HEAD On Wed, Jan 14, 2015 at 12:32 PM, Ana Pazos <apazos at codeaurora.org> wrote: > Daniel, your patch does not apply cleanly. Are you on the tip? > > The code I see there is no line if (QueryResult == MayAlias|| QueryResult == PartialAlias)

In lto+pgo some (5 out of 12 with usual suspect like perlbench and gcc among them using -flto -Wl,-mllvm,-use-cfl-aa -Wl,-mllvm,-use-cfl-aa-in-codegen) the CINT2006 benchmarks don’t compile. Has the implementation been tested with lto? If not, please stress the implementation more. Do we know reasons for gains? Where did you expect the biggest gains? Some of the losses will likely boil down to

----- Original Message ----- > From: "Gerolf Hoflehner" <ghoflehner at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Jiangning Liu" <liujiangning1 at gmail.com>, "George Burgess IV" > <george.burgess.iv at gmail.com> > Sent: Monday, September 15, 2014

It's found more and more like "get CFL-AA turned on by default" might be a viable GSoC project for the right student. It would require someone with existing knowledge of AA and a willingness to debug nasty problems, but it sounds like there's definitely interest in the community in seeing this happen. If the student finished early (unlikely), they could start on SCEV-AA as

On CINT2006 ARM64/ref input/lto+pgo I practically measure no performance difference for the 7 benchmarks that compile. This includes bzip2 (although different source base than in CINT2000), mcf, hmmer, sjeng, h364ref, astar, xalancbmk On Sep 15, 2014, at 11:59 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Gerolf Hoflehner"

It's something that I am certainly interested in and qualified to do. However, the way I read Daniel's reply in this thread is: "LLVM, in its current form, is unlikely to benefit from a more precise aa". He did mention that cfl-aa is "more understandable and maintainable", and is "fast enough", but nothing is said about the benefits. There was some

----- Original Message ----- > From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Renato Golin" <renato.golin at linaro.org>, "George Burgess IV" > <george.burgess.iv at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Jia Chen" > <jchen at cs.utexas.edu> > Sent: Monday,

Hi Geoff, Thank you so much for the effort! It's good to hear that cfl-aa didn't break anything. However, the fact that it doesn't quite affect code generation is also concerning. I'll definitely look into the issue. On 05/19/2016 02:03 PM, Geoff Berry wrote: > Hi Jia, > > We did some testing with CFL-AA enabled on an aarch64 OoO target on the > llvm test-suite and

Yes. I've attached an updated patch that does the following: 1. Fixes the partialalias of globals/arguments 2. Enables partialalias for cases where nothing has been unified to a global/argument 3. Fixes that select was unifying the condition to the other pieces (the condition does not need to be processed :P). This was causing unnecessary aliasing. 4. Adds a regression test to