search for: rdopts

Hi, I found that some loops can not be identified by LoopInfo pass. For example, the loop at line 3094 of rdopt.c of benchmark 464.h264ref from spec cpu2006 is not a loop or a child (pr grandchild) of any loop in the loop list generated by LoopInfo pass. The documentation of LoopInfo says that it identifies natural loops, who have exactly one entry point. But the IR of this loops shows that

I've just committed some fairly big changes to R-devel. - There's a new tag \Sexpr which allows R code to be embedded within the Rd file, similar to Sweave, \RdOpts corresponds to \SweaveOpts. - The parser now mainly issues warnings, rather than errors, in case of syntax errors. It throws away a few tokens and tries to restart. This should let you see most of your errors in one pass, rather than one at a time. (Don't ignore the warnings -- you&...

In C code, if a loop is not a natural loop, that means its loop body should at least have one label, right? In that case, some BB out of the loop can jump to the loop body, so the loop has more than on entry. Does LoopInfo guarantee to identify all natural loops? This property is very important for my pass. regards, Bo On Fri, Apr 29, 2011 at 11:50 PM, Cameron Zwarich <zwarich at

A natural loop is one whose header dominates all of the nodes in the loop. There is probably some block outside of the loop jumping to a block in the loop body. Cameron On Apr 29, 2011, at 7:43 PM, Bo Wu <bwu at cs.wm.edu> wrote: > Hi, > > I found that some loops can not be identified by LoopInfo pass. For example, the loop at line 3094 of rdopt.c of benchmark 464.h264ref from

On 4/30/11 8:52 AM, Bo Wu wrote: > In C code, if a loop is not a natural loop, that means its loop body > should at least have one label, right? In that case, some BB out of > the loop can jump to the loop body, so the loop has more than on entry. Off the top of my head, I would think you are right: a C label would have to exist within the loop in order to have a jump from outside the

Dear testers, 5.0.0-rc3 was just tagged. This is a release candidate in the real sense: if nothing bad comes up in testing, this is what the release is going to look like. Please build, test and upload binaries to the sftp (use the /data/testers-uploads/ directory) and let me know what issues remain. I know we're a little bit behind schedule, but hopefully we can get to 'final'

Thanks for the reply. The LoopInfo pass can actually identify the loop I mentioned. My former question is due to a bug in my pass. What I worried is that LoopInfo can not identify all the natural loops for the benchmarks I use, but now I haven't found any such cases. Bo On Sun, May 1, 2011 at 4:24 PM, John Criswell <criswell at illinois.edu> wrote: > On 4/30/11 8:52 AM, Bo Wu

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

Hello Sean and Tobias, Sean, Thank you. Could you describe Nick's ideas in few words or give me links to your discussion, so I could adapt my ideas to it. Tobias, Your patch fails on several modules in my benchmark (73 of ~1800 tests). I have sent one as attachment. See statistics files for more details, all the .ll files you could simply find in test-suite object directory (after