similar to: [LLVMdev] Does LLVM optimize recursive call?

On Wed, Oct 3, 2012 at 10:15 AM, Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> wrote: > Preston Briggs <preston.briggs at gmail.com> writes: >> Think about costs asymptotically; that's what matters. Calls and >> returns require constant time, just like addition and multiplication. > > Constant time, but not necessarily constant memory. > > Deep recursion

> Only if the recursion is very deep. In practice, a recursive descent > parser isn't going to run out of stack space, nor will a quicksort or > binary-tree walker, The recursive-descent parser case has happened in practice: http://my.opera.com/hallvors/blog/2012/07/17/twitter-crashes-itself-with-commas?1 Also, I've seen some recursion-related PR's in Clang, although I think

Preston Briggs <preston.briggs at gmail.com> writes: > Think about costs asymptotically; that's what matters. Calls and > returns require constant time, just like addition and multiplication. Constant time, but not necessarily constant memory. Deep recursion will blow up your stack (AKA "segmentation fault" :-( ) if the compiler could not optimize it (tail recursion

Valmico <valmico88 at gmail.com> wrote: > I'm currently trying to develop new LLVM Pass that will generate > simple data dependencies graph. For now I'm trying to get familiar > with DependenceAnalysis. > My general idea is to traverse each function (runOnFunction) > top to bottom Instruction by Instruction, using DA.depends( I, I2, ...) > on every Instructions

On Tue, Oct 2, 2012 at 11:44 PM, Journeyer J. Joh <oosaprogrammer at gmail.com> wrote: > Hi list, > > I have a simple question about LLVM. > > I learned that we need to use iterations than recursions in C programming. > That is because recursion is expensive. It can easily consume out all > the stack given to a program. And the call/return consumes time much > more.

greened at obbligato.org (David A. Greene) writes: > Actually git pull can sometimes get you into trouble. Probably git > fetch / git rebase is the better combination for LLVM. I don't get it. Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Hi David Blaikie and others who might be interested on this Thank you very much! #1. Then I'd like to know, to make Clang/LLVM optimize a recursion into an iteration, how a recursion has to be implemented with any compiler option? (if the language is C/C++) Clang uses recursions, especially it uses recursive decent and operator-precedence parser. #2. I wonder if this kind of recursion is

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > greened at obbligato.org (David A. Greene) writes: > >> Actually git pull can sometimes get you into trouble. Probably git >> fetch / git rebase is the better combination for LLVM. > > I don't get it. > > Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? No. It does

Ok, the LLVM 2.7 release notes are in near final shape. Please take a look and suggest improvements (or, better yet, just commit improvements if you have commit access): http://llvm.org/docs/ReleaseNotes.html Things still needed are marked with FIXMEs. These include: 1. Clang needs a blurb describing what's new in 2.7. Have the clang folks been doing anything for the last 6 months? 2. I

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to

greened at obbligato.org (David A. Greene) writes: >> b) We need a document explaining how patches are reviewed and referred >> to, what commit rules (and hooks) are in place and how this would work >> in a git world. It would be short and sweet. > > I'm not exactly sure what you're asking for. My assumption is that the > hooks in place for git are the same

Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.

Hi, The link "Broken versions of GCC and other tools" on http://llvm.org/docs/ReleaseNotes.html points to #brokengcc, where it should point to http://llvm.org/docs/GettingStarted.html#brokengcc I guess. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > The problem is answering the question of "do I have it or not". Linear > version numbers are much nicer for that. In the presence of branches, the version number alone doesn't answer this question, because the commit may be more recent than your HEAD, but in another branch. git branch --contains <sha1>, on

John McCall <rjmccall at apple.com> writes: >> git branch --contains <sha1>, on the other hand, will tell you. > > Of course, this doesn't actually help if you've cherry-picked commits > over to your branch (e.g. because it's a release branch). How is that different from SVN? If revision 1234 fixes a bug is some branch, and the last revision in your trunk

Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to generate the patch file against revison 167719 ? Thanks in advance. On

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > dag at cray.com (David A. Greene) writes: > >> Jason Kim <jasonwkim at google.com> writes: >> >>> I believe git has a similar system for maintaining "branches of patches"  >> >> A pointer/tutorial on how to do this would be most welcome. > > It depends on the definition of

On 11/02/2012 11:02 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Tobias Grosser" <tobias at grosser.es> >> To: "preston briggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November

> What options were used with git-svn init?  It certainly can support > multiple branch/tag directories: > > init >  --tags=<tags_subdir> >  --branches=<branches_subdir> > >  You can specify more than one --tags and/or --branches options, in >  case your Subversion repository places tags or branches under multiple >  paths. The svn repository is free to

The phi instruction is irrelevant; just the way I think about things. The question is if the allocator believes that t0 and t2 interfere. Perhaps the coalescing example was too simple. In the general case, we can't coalesce without a notion of interference. My worry is that looking at interference by ranges of instruction numbers leads to inaccuracies when a range is introduced by a copy.