search for: rec_func

Hi llvm-devels, there is a very simple using case concerning LLVM and I am wondering whether it might be optimized at LLVM layer: //----------- int rec_func(int x, int y) { if(y<0) return x; return y + rec_func(x, y-1); // should we really push x? } void main() { rec_func(1, 1000); rec_func(2, 2000); } //----------- Guys, don't focus on a stupid mathematics beyond this function :) Please focus your attention at the fact, that argument `...

...closure. > > Can you explain more about what you mean. I don't think I understand. I will try. But then perhaps I should separte statements in order to know where I was unclear. S1. Example just shows simple phenomenon when every recursive (i.e. not from main) call of function `rec_func' does *not* change variable `x' anymore. It means, that every recursive call just makes extra/redundant copy of the `x'. S2. Theoretically this redundant copy might be eliminated. The idea is simple: at first (i.e. non-recursive) call generate `rec_func' code...

Hello Chris, Tuesday, August 26, 2003, 11:02:45 PM, you wrote: >> there is a very simple using case concerning LLVM and I am wondering >> whether it might be optimized at LLVM layer: >> >> //----------- >> int rec_func(int x, int y) { >> if(y<0) return x; >> return y + rec_func(x, y-1); // should we really push x? >> } CL> Probably not, at least not in the near future. At some point I have had CL> thoughts about implementing a tail recursion pass, but without prior CL> transfor...

...t; To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] repeated recursion with "frozen" arguments > > > Hi llvm-devels, > > there is a very simple using case concerning LLVM and I am > wondering whether it might be optimized at LLVM layer: > > //----------- > int rec_func(int x, int y) { > if(y<0) return x; > return y + rec_func(x, y-1); // should we really push x? > } > void main() { > rec_func(1, 1000); > rec_func(2, 2000); > } > //----------- > > Guys, don't focus on a stupid mathematics beyond this function :) > Pl...

> there is a very simple using case concerning LLVM and I am wondering > whether it might be optimized at LLVM layer: > > //----------- > int rec_func(int x, int y) { > if(y<0) return x; > return y + rec_func(x, y-1); // should we really push x? > } Probably not, at least not in the near future. At some point I have had thoughts about implementing a tail recursion pass, but without prior transformation, this function would not b...

...that if even so, I got two similar and concrete > answers already: > "it is suitable for LLVM, though not implemented yet" > :) :) > S2. Theoretically this redundant copy might be eliminated. > The idea is simple: at first (i.e. non-recursive) call > generate `rec_func' code which does not push `x' on > the stack because it will remain the same from the > first non-recursive call. For example initial > non-recursive call `rec_func(1, 1000)' should be > instantiated as: Ok, Vikram is right. This is known as procedure cloni...

<Chris is cleaning out his inbox> Valery A.Khamenya wrote (in http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-August/000455.html): > there is a very simple using case concerning LLVM and I am wondering > whether it might be optimized at LLVM layer: > int rec_func(int x, int y) { > if(y<0) return x; > return y + rec_func(x, y-1); // should we really push x? > } > The similar things we have when we pass `this' pointer to non-static > member functions in C++ (why should we pass `this' pointer always if it > was not changed?)....

.../ GC handling for item data objects </span><span class="cx"> %{ </span><del>- static void RecursivelyGCMarkFrom(wxTreeCtrl *tree_ctrl, wxTreeItemId base_id ) </del><ins>+ // general recursion over a treectrl, starting from a base_id + // the function rec_func will be called in turn for each tree item, + // rec_func should be a funtion that receives a treectrl pointer and an ItemId + static void RecurseOverTreeIds(wxTreeCtrl *tree_ctrl, const wxTreeItemId& base_id, void(*rec_func)(void *, const wxTreeItemId&) ) </ins><span class=&quot...

Hi all, So I have finally finished the v1 of reflink for ocfs2. It has some bugs that I am still investigating, but the schema is almost there. So I'd like to send it out first for review. And Tristan and I will continue to work on the stability of the code. The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink. For the design doc, please

Hi all, Change from v1 to v2: bug fix and metadata/credits reservation improvement. The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink. For the design doc, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/RefcountTrees http://oss.oracle.com/osswiki/OCFS2/DesignDocs/ReflinkOperation

Hi all, So I have finally finished the v3 of reflink for ocfs2. The biggest change is that we support 64bit cluster offset now(Thank Mark and Joel for it). [View] http://oss.oracle.com/git/?p=tma/linux-2.6.git;a=shortlog;h=refcount [Pull] git://oss.oracle.com/git/tma/linux-2.6.git refcount The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink.