similar to: [LLVMdev] quantitative comparison of correctness of llvm-gcc 2.x versions

Unfortunately, the data in the paper doesn't show that, through no fault of the authors :-(. It might be nice to add a qualification and a pointer to this graph along with the paper, if John doesn't object. --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Nov 18, 2008, at 12:33 PM, Chris Lattner wrote: > >

On Nov 18, 2008, at 10:08 AM, John Regehr wrote: > http://www.cs.utah.edu/~regehr/compiler_correctness/llvm_gcc_x86/ > > I think these graphs speak for themselves. Feedback is welcome. Hey, it looks like we made some progress. ;-) Would you mind if I added your paper to llvm.org/pubs? -Chris

Please link to the graphs if that seems appropriate-- I will leave them there and hopefully also update them as new versions of LLVM come out. It would be great if these graphs can serve as an advertisement for LLVM as well as an advertisement for my work. I hope to create analogous graphs for gcc 4.x sometime, and also to stress-test the x64 ports of both compiler families. There is a

On Nov 18, 2008, at 12:25 PM, John Regehr wrote: > Please link to the graphs if that seems appropriate-- I will leave > them > there and hopefully also update them as new versions of LLVM come out. > It would be great if these graphs can serve as an advertisement for > LLVM > as well as an advertisement for my work. I hope to create analogous > graphs for gcc 4.x

[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

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

See here: http://embed.cs.utah.edu/embarrassing/ There is a lot of data there. Please excuse bugs and other problems. Feedback would be appreciated. John Regehr

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,

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

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.

On 12/16/2009 03:21 AM, John Regehr wrote: > Hopefully the results are more fair and useful now. Again, feedback is > appreciated. I would also avoid testcases using volatile. Smaller code on these testcases is often a sign of miscompilation rather than optimization. For example, http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is miscompiled on GCC 3.4 and SunCC

Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an

Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:

As part of routine testing, I run clang and llvm-gcc a lot of times. Something happened between r83681 and r84167 such that clang-cc and cc1 became many hundreds of times slower when asked to perform optimizations. Is this a known issue? These are all release builds on Ubuntu Jaunty on x86. During these long runs, memory usage creeps up slowly at maybe 1 MB per minute. Thanks, John Regehr

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

We (the folks working on Souper) would appreciate any feedback on these IR-level superoptimizer results: http://blog.regehr.org/extra_files/souper-jul-15.html My impression is that while there's clearly plenty of material in here that doesn't want to get implemented in an opt pass, there are a number of gems hiding in there that are worth implementing. Blog post containing

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

I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,

On Dec 14, 2009, at 7:33 AM, John Regehr wrote: > See here: > > http://embed.cs.utah.edu/embarrassing/ > > There is a lot of data there. Please excuse bugs and other problems. > Feedback would be appreciated. Hi John, I agree with the gcc folks: it's really important to get frame pointer emission etc aligned across the various compilers. ICC defaulting to frame

On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote: > On 12/16/2009 03:21 AM, John Regehr wrote: >> Hopefully the results are more fair and useful now. Again, feedback is >> appreciated. > > I would also avoid testcases using volatile. Smaller code on these > testcases is often a sign of miscompilation rather than optimization. > For example, >