similar to: [LLVMdev] ANTLR?

That sounds like a problem. Just so I understand, do you mean there isn't the run-time support etc. to write back ends for the C++ language, or that the compiler IR is also somehow insufficient to write a code generator? --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Jul 11, 2009, at 3:00 PM, Granville Barnett

For a LL(1) parser, it might be a little bit difficult to parse complex grammar like C++, but it might work. ANTLR worked great when other codes were written in Java, but it was a little bit painful when using other languages like python. I worked on it two years ago. I guess they might have some improvement now. Haohui On 07/11/2009 02:40 PM, Vikram S. Adve wrote: > We are looking for an

Hi, I've not got any experience using ANTLR to parse C++, however, you will find that there only exists a C code generator for ANTLR and NOT a C++ one. Over the years numerous people have requested a C++ code generation template but alas there is still only a C one. Just a heads up. Granville 2009/7/11 Vikram S. Adve <vadve at cs.uiuc.edu> > We are looking for an open source C++

When you create a parser via ANTLR you specify the output language of the resulting recursive descent parser, at the moment there exists no C++ output template to my knowledge, thus you would have to generate the parser as C code for which a template exists. The runtime support should be there, at least partially but it won't use things like exceptions, nor will it have a very modular design

On Jul 11, 2009, at 12:40 PM, Vikram S. Adve wrote: > We are looking for an open source C++ parser other than g++ if > possible. Clang would be great but its C++ support is still some > way away and we need something that works or nearly works now. Does > anyone have any experience with ANTLR for parsing C++ and for > extending their C++ parser? Any other feedback on

I've done extensive research on the subject and if you want to parse ALL of C++, there are only two options, g++ or the Edison Design Group C++ front-end. Both of these have projects designed to make this easier LLVM (as you know) and Rose (http://www.rosecompiler.org/), which works with the EDG compiler. AspectC++, OpenC++, Antler, TLX, all work with only a portion of the grammer. On Sat,

Right, I understand that. I was hoping there was such an implementation using ANTLR since it looks like a fairly mature project. I'm not sure how stable or mature Elsa is (but comments to clarify that would be appreciated.). E.g., a quick scan of their Web page shows the comment that they only have a partial type checker. It also says their template instantiation is incomplete.

On Jul 11, 2009, at 1:41 PM, Vikram S. Adve wrote: > Right, I understand that. I was hoping there was such an > implementation using ANTLR since it looks like a fairly mature > project. Not that I'm aware of. > I'm not sure how stable or mature Elsa is (but comments to clarify > that would be appreciated.). E.g., a quick scan of their Web page > shows the

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 Oct 15, 2009, at 10:45 AM, Chris Lattner wrote: > Unfortunately, we found out at the last minute that Apple has a rule > which prevents its engineers from giving video taped talks or > distributing slides. We will hold onto the video and slide assets in > case this rule changes in the future. > > -Chris Chris, I hope you can pass my message along to the people at Apple

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

Dear all, Is anyone aware of any implementation of an inter procedural slicing algorithm for LLVM? I am mostly interested in a static algorithm but a dynamic one can be helpful too. Thanks, Silviu Ganceanu Research Student, Ecole Polytechique Federale de Luasanne -------------- next part -------------- An HTML attachment was scrubbed... URL:

First, kudos on the ThinLTO results reported in your blog post — they’re impressive and the system sounds really well engineered. I’m starting to try it out on a large piece of software and I’d like to make sure I know what to expect. The blog said it will be available in clang-3.9 but both clang-3.8 and trunk seem to have some degree of support for it. What is the status of ThinLTO in 3.8

We have done a few class projects on static interprocedural slicing but they are all of "course project" quality. I will put you in touch with some of the students who did those, if you're interested? --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Aug 15, 2008, at 8:48 AM, Silviu-Ionut Ganceanu wrote:

Sparc is a popular target for architecture simulators, and removing that back end would force people using such simulators to use some other compiler infrastructure. Sparc is also useful for University courses. I'd strongly discourage removing this back end. --Vikram Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Oct 25, 2011, at 4:00

Hal, Andrey, Alexey, >From the LLVM design viewpoint, there is a fundamental problem with both Hal's approach and the Intel approach: both are quite language-specific. OpenMP is a particular parallel language, with particular constructs (e.g., parallel regions) and semantics. LLVM is a language-neutral IR and infrastructure and OpenMP-specific concepts should not creep into it. I've

I too am disappointed that not all talk slides are posted. To me it speaks poorly of the whole meeting since there were parallel sessions and not everyone could attend in person all the sessions they wanted to. The slides are, I thought, meant to be like the "proceedings" and If I recall some of the Apple slides are present from previous years but not this year. Vinod On Sat, Oct 17,

On Wed, 25 Mar 2009, Vikram S. Adve wrote: > We do have a static array bounds checking algorithm based on the Omega > integer programming library, but it is not hugely effective. I think > this can be strengthened a *lot*. I should add that I would be interested in helping with hooking a good decision procedure into LLVM. This will be useful far beyond array bounds check

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

I'm trying to decide whether to use either the MIPS or ARM back ends for course projects in our introductory compiler class. I'd like to use something that has a stable back end, so that the students can use the selector, probably without changes, and do a project on register allocation and stack layout. We don't have MIPS or ARM hardware (other than possibly a few donated Android