similar to: [LLVMdev] testing ABCD?

I am trying to employ the ABCD optimization pass to remove unnecessary branches in the code my compiler generates. But in its current form (yesterday's trunk) the pass changes the behavior of the code such that execution yields invalid results, which is obviously not what I want. The switch in the following listing is used to implement a virtual method call, 99999 and 100000 are type

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

A longstanding project on the LLVM "open projects" page is to run random C code through random LLVM passes. We have found many LLVM bugs by doing the first of these, but not the second: we test only -O[0123s]. Slowly but surely, LLVM is evolving resistance to our random tester. Of course this is good, but it means that we need to keep expanding our efforts if we want to continue

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 2009-11-19 22:16, John Regehr wrote: > A longstanding project on the LLVM "open projects" page is to run random > C code through random LLVM passes. > > We have found many LLVM bugs by doing the first of these, but not the > second: we test only -O[0123s]. > > Slowly but surely, LLVM is evolving resistance to our random tester. Of > course this is good, but

yiqiuping1986 wrote: > Hi， John Criswell！ > You have said to me that SAFECode had not been maintained for several > years, Just to clarify, SAFECode *has* been and *is* maintained (primarily by me). The release_26 branch in the SVN repository works with LLVM 2.6, and mainline is working (with some regressions) with the upcoming LLVM 2.7. You can subscribe to the SVA Commits mailing list

On Sat, Oct 14, 2017 at 11:05 AM, John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > These are definitely LLVM bugs. It would be best to report reduced test > cases against top of tree. > > We should have some automated infrastructure for finding these too... > > John > Zhendong & friends generally do that (and reported many bugs :) I tried that myself,

On Feb 15, 2009, at 10:08 PM, John Regehr wrote: >> Predsimplify is believed to have bugs (it results in miscompiled >> programs) and certainly isn't efficient (it was written before much >> of >> include/ADT). Finally, predsimplify is likely to go away once I or >> someone else writes a proper VRP pass. > > Whoever does this, I strongly encourage looking

Vikram S. Adve wrote: > On Jun 5, 2009, at 9:26 AM, Mai, Haohui wrote: > > >> By static array bounds checking, I mean eliminating array bounds >> checking >> which can be proved ``safe'' at compile-time. >> > > Even though SAFECode does have such a pass, there are some tradeoffs > with the current version: > > 1. It uses an

By static array bounds checking, I mean eliminating array bounds checking which can be proved ``safe'' at compile-time. Well, even though there are a lot of approaches of doing this, I believe that having an implementation of ABCD would very useful. It would be even more useful if LLVM can have a general framework for doing static array bounds checking -- just like the aliasing framework.

On Jun 5, 2009, at 9:26 AM, Mai, Haohui wrote: > By static array bounds checking, I mean eliminating array bounds > checking > which can be proved ``safe'' at compile-time. Even though SAFECode does have such a pass, there are some tradeoffs with the current version: 1. It uses an external solver (Omega), which is one more dependence for LLVM in general. I don't have

Mai, Haohui wrote: > Dear Nicolas, > > I'm curious why you are using ABCD in vmkit. Do you need any features > from static array bounds checking? As far as I know, SAFECode has a > number of implementation for that. > > Thanks. > > Haohui > > On Thu, 2009-06-04 at 20:48 +0200, Nicolas Geoffray wrote: > >> Dear Andre, >> >> That's

Dear Nicolas, I'm curious why you are using ABCD in vmkit. Do you need any features from static array bounds checking? As far as I know, SAFECode has a number of implementation for that. Thanks. Haohui On Thu, 2009-06-04 at 20:48 +0200, Nicolas Geoffray wrote: > Dear Andre, > > That's great! Thanks for the blog. I am really looking forward into > using ABCD in vmkit!

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

We have some results that are somewhat entertaining and that relate to the size/speed discussion. The basic idea is exhaustive generation of C functions where "exhaustive" is qualified by some structural restrictions (depth of AST, node type, etc.). For one particular set of restrictions we ended up with about 7 million C functions. We then compiled each of these functions with 7

Dear Andre, That's great! Thanks for the blog. I am really looking forward into using ABCD in vmkit! Cheers, Nicolas Andre Tavares wrote: > Dear Community, > > I'm working on a project for Google Summer of Code, to implement the > ABCD and Bitwidth analysis in LLVM. I'm not going to extend the > description of the project here, this link shows my proposal >

> Predsimplify is believed to have bugs (it results in miscompiled > programs) and certainly isn't efficient (it was written before much of > include/ADT). Finally, predsimplify is likely to go away once I or > someone else writes a proper VRP pass. Whoever does this, I strongly encourage looking into using (or at least providing optional support for) the Apron library:

Thanks Duncan and Edwin-- looking at the passes used everyday sounds like the right approach. > Also I think you should also try to test LLVM IR features that are less > often used: > byval, weak linkage, ssp, structs with unusual layout/alignment, vector > operations, > multiple return values, indirectbr, atomic ops, lifetime/invariant > annotations, etc. Well, we are

Dear Community, I'm working on a project for Google Summer of Code, to implement the ABCD and Bitwidth analysis in LLVM. I'm not going to extend the description of the project here, this link shows my proposal http://homepages.dcc.ufmg.br/~andrelct/projects/gsoc_2009/proposal. I have been in some discussions on this list about Ada and SSI that helped on my decisions up to this

Hi， John Criswell！ You have said to me that SAFECode had not been maintained for several years, now I have submitted my proposal for updating the SAFCode project to the new LLVM APIs. If you are still interested in the topic and willing to guid my project, I will be very happy. Now I'm waiting for you comments. Here is my proposal: