similar to: [LLVMdev] some llvm/clang missed optimizations

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 >>> >>>

> 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 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

On Tue, Jan 26, 2010 at 7:42 PM, John Regehr <regehr at cs.utah.edu> wrote: >> 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: > >

> I started looking through the llvm-gcc vs. clang comparisons, and > noticed that in > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/A9/A9AB5AE7.c > , size_t is declared incorrectly. Any idea how that might have > happened? Hi Eli, Thanks for pointing this out, I'll look into this tonight. However I can give you the quick generic answer right now (of course

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

On Wed, Jan 20, 2010 at 12:05 PM, John Regehr <regehr at cs.utah.edu> wrote: >> I started looking through the llvm-gcc vs. clang comparisons, and >> noticed that in >> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/A9/A9AB5AE7.c >> , size_t is declared incorrectly.  Any idea how that might have >> happened? > > Hi Eli, > > Thanks for

On 01/20/2010 05:54 PM, John Regehr 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 > > - added the x86 Open64

First, I love R and am grateful to be using this free and extremely high quality software. Recently I have been comparing two algorithms and naturally I programmed in R first. It is so slow that I can almost feel its pain. So I decided to do a comparison with Java. To draw 500,0000 truncated normal, Java program takes 2 second and R takes 72 seconds. Not a computer science major, I find it hard

R-Users, I am working with gplots (in gregmisc bundle) plotting some posterior probabilities (using barplot2) of harvest bag limits for discrete data (x-axis from 0 to 12, data is counts) and I ran into a couple of questions whose solutions have evaded me. 1) When I create and include the confidence intervals, the lower bound of the confidence intervals for several of the posterior probabilities

Hi there I'm trying to find the mle fo a multinomial model ->*L(N,h,S?x)*. There is only *N* I want to estimate, which is used in the number of successes for the last cell probability. These successes are given by: p^(N-x1-x2-...xi) All the other parameters (i.e. h and S) I know from somewhere else. Here is what I've tried to do so far for a imaginary data set:

Hello everybody, In am trying to analyse a BACI experiment and I really want to do it with R (which I find really exciting). So, before moving on I though it would be a good idea to repeat some known experiments which are quite similar to my own. I tried to reproduce 2 published examples but without much success. The first one in particular is a published dataset analysed with SAS by

Hi, I have written a function "harvest" and I would like to run the function for each value in a vector c(1:1000). The function returns 4 list objects (obj_1, obj_3, obj_3, obj_4) using the following code at the end of the function: return(list(obj_1 = obj_1, obj_2 = obj_2, obj_3 = obj_3, obj_4 = obj_4)). Since I am connecting with the web in the function and the connection sometimes

There's some interest in my "auto-simplifier", which is nice :), so let me explain a bit about it. On 19/01/11 19:35, Sandeep Patel wrote: > You've mentioned your auto-simplifier a few times now and curiosity is > getting the better of me. Can you explain it a bit more? On 20/01/11 00:32, Nuno Lopes wrote: > Just out of curiosity, what's this auto-simplifier?

Dear list, Given a linear mixed model (from lme4) I want to 1) first change the input dataset and then 2) change the model formula. I want this to happen in a function call; Please see below. Options 1) and 2) below work whereas 3) fails with the message > foo() Error in is.data.frame(data) : object 'beets2' not found Question: What is it one must to in case 3) to have R look

[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

Is there a way to listen on port 25 for repeated dictionary attacks to harvest email address and blacklist that Ip with shorewall? Thanks, Mike

> The issue here is more arbitrary differences due to different default > code generation choices; for example, clang defaults to generating > SSE2 code, while llvm-gcc defaults to using x87 FP. Aha, this explains some apparently bizarre results such as the second one (018427, d) on this page: http://embed.cs.utah.edu/embarrassing/dec_09/harvest/llvm-gcc-head_clang-head/ I had been