similar to: [LLVMdev] compiler code coverage

Hi! I'm new to R, and I have a question about how R works with large data sets --- in particular, data sets that come from databases. I'm using R 2.2.0 with the DBI package (0.1-9) and the RMySQL package (0.5-5). My get-my-feet-wet-with-R project is to make a histogram from a data set stored in a MySQL database. In particular, I have a table that describes some observed spam emails.

Can anyone help me find a code coverage tool in ruby? What I want is: given a set of tests that I run, what lines of my code and what routines are covered. And also a list of uncovered routines and tests. I couldn''t find an open source one out there... -- www.kenlet.com

A few random observations: 1. Clang could do better with large but boring switches like this: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/E8/E88C5111.shtml Performance of clang's output will be fine but this is a major code size lose. 2. Destruction of stupid loops is incomplete, sometimes due to phase ordering problems:

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

> Umm, can you find one that isn't a popcount implementation? Ok. MMX psadbw instruction: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/CE/CE3DA132.shtml Position of first set bit: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/1F/1F4003C7.shtml Log2 floor: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/83/837A80E9.shtml Pixel format

On Tue, Jan 26, 2010 at 12:36 PM, John Regehr <regehr at cs.utah.edu> wrote: > 2. > Sometimes not: > > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/EC/ECC74C0C.shtml The primary issue here is that scalar evolution doesn't know how to deal with loops using "sle" for the exit condition. Shouldn't be too hard to fix now that we have overflow flags

>> Repetitive code with lots of bitwise operations is compiled by LLVM into >> much larger code than the other compilers: >> >> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/ED/ED37DAF5.shtml >> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/1F/1F4003C7.shtml >> >> Note that this is straight-line code, so LLVM's output will

On Tue, Jan 26, 2010 at 5:55 PM, John Regehr <regehr at cs.utah.edu> wrote: >>> Repetitive code with lots of bitwise operations is compiled by LLVM into >>> much larger code than the other compilers: >>> >>> >>> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/ED/ED37DAF5.shtml >>> >>>

On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.

Hi all, Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. While I don’t necessarily think it’s ideal to ignore all noreturn decls, I think there’s definitely room for some heuristics around ignoring things like llvm_unreachable (perhaps opt-in?). I’m

My InlineCost refactoring has been noticed in this aspect; that may or may notbe the culprit here. A quick thing you can do is to compile with -ftime-report and compare the top few passes between versions. Dan On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote: > As part of routine testing, I run clang and llvm-gcc a lot of times. > Something happened

+ cfe-dev > On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. FWIW, Daniel Dunbar and a few others have brought up the lack of a

One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,

Hi folks, I've posted an updated code size comparison between LLVM, GCC, and others here: http://embed.cs.utah.edu/embarrassing/ New in this version: - much larger collection of harvested functions: more than 360,000 - bug fixes and UI improvements - added the x86 Open64 compiler John

I'm pretty sure that isn't what nnan is supposed to mean. If the result of nnan math were undefined in the sense of "undef", programs using nnan could have undefined behavior if the result is used in certain ways which would not be undefined for any actual float value (e.g. converting the result to a string), which seems like a surprising result.  And I don't think we

[cross-posting to the GCC and LLVM lists] I've updated the code size results here: http://embed.cs.utah.edu/embarrassing/dec_09/ The changes for this run were: - delete a number of testcases that contained use of uninitialized local variables - turn off frame pointer emission for all compilers - ask all compilers to target x86 + SSE3 - ask all compilers to not emit stack protector

We have a bitwidth analysis that can be downloaded. It is not in LLVM. There should be a link in the paper: http://www.cs.utah.edu/~regehr/papers/pldi075-cooprider.pdf John Regehr

Hi everyone, On Monday, November 14, 2016 the LLVM in HPC workshop will be held in Salt Lake City, Utah (in conjunction with the SC16 conference). For last year's workshop, which was in Austin, we held an LLVM social the evening of the workshop, and I think that turned out really well. If you'll be in Salt Lake City and are interested in attending an LLVM social on the evening of November

http://www.cs.utah.edu/~regehr/compiler_correctness/llvm_gcc_x86/ I think these graphs speak for themselves. Feedback is welcome. John Regehr

On Wed, Jan 20, 2010 at 7:54 AM, John Regehr <regehr at cs.utah.edu> wrote: > Hi folks, > > I've posted an updated code size comparison between LLVM, GCC, and > others here: > >   http://embed.cs.utah.edu/embarrassing/ > > New in this version: > > - much larger collection of harvested functions: more than 360,000 > > - bug fixes and UI improvements