similar to: [LLVMdev] LLVM namespac'ification

Yes, pretty much. There are a few things that will go in the std namespace because its the way it is and a more natural fit. The other two namespaces already in use (cl and DOT) will be placed under the llvm namespace. The goal is to get everything that is currently at top level and put it in llvm. This means that in your programs, you wouldn't use: cl::XYZ anymore but: llvm::cl::XYZ. Or,

On Sun, 9 Nov 2003, Rahul Joshi wrote: > Coming back to the issues that I had integrating LLVM with > MSSP, will the code in include/Support also be put in the > llvm namespace? That will solve many problems and help prevent > others. Absolutely. -Chris > ---- Original message ---- > >Date: Sun, 9 Nov 2003 10:13:03 -0600 (CST) > >From: Chris Lattner <sabre at

Coming back to the issues that I had integrating LLVM with MSSP, will the code in include/Support also be put in the llvm namespace? That will solve many problems and help prevent others. Rahul ---- Original message ---- >Date: Sun, 9 Nov 2003 10:13:03 -0600 (CST) >From: Chris Lattner <sabre at nondot.org> >Subject: [LLVMdev] LLVM namespac'ification >To: LLVMdev List

On Wed, 14 Apr 2004, Reid Spencer wrote: > The only thing I can think of is that string.h is being #included and > has different signatures for memcpy and strncpy. Possibly "char" is not > signed on your machine (very unusual) or some of the parameters are > declared as "const". The problem is that the code generated by the C backend cannot include any system

I just found "entry". Its the name I gave a basic block at the start of the function (name was hard coded in the compiler, not the source). The issue here is probably that the block doesn't have a terminating instruction. However, that fact used to be caught well by the validator. Furthermore, the output from the byte code reader is a little confusing given the source of the

On Sat, 30 Dec 2006, Reid Spencer wrote: > You all just need remove "stacker_rt.ll". the stacker_rt.ll is a > generated file, not source. The Makefile should have a dependency on > llvm-gcc for it, but doesn't. Just remove stacker_rt.ll and the problem > will go away. This presumably doesn't impact the testers, as they start from a clean build every night. The

On Thu, 11 Nov 2004, Reid Spencer wrote: > This kind of thing is one of the many reasons we broke llvm-test out to > a separate project. It has multiple purposes. Its a correctness test on > LLVM, its what we base our compiler benchmarks on, and its also where a > lot of the research gets done. You've been bitten by the latt(n)er. :) > > At some point I'd like to see us

On Wed, 4 Aug 2004, Reid Spencer wrote: > On Wed, 2004-08-04 at 12:23, Misha Brukman wrote: > > On Wed, Aug 04, 2004 at 12:16:12PM -0700, Reid Spencer wrote: > > > So I propose: > > > > > [snip] > > > -O3 = aggressive optimization, regardless of computation time with the > > > effect of producing the fastest executable > > > >

On Thu, 15 Jul 2004, Reid Spencer wrote: > On Thu, 15 Jul 2004 18:05:21 -0500 (CDT) > Chris Lattner <sabre at nondot.org> wrote: > > > BTW, for those who are interested in the differences between 1.2 and CVS, > > check out: http://llvm.cs.uiuc.edu/docs/ReleaseNotes.html#whatsnew > > It might be a good idea to add a check-in script that puts the latest >

On Wed, 18 Oct 2006, Reid Spencer wrote: > How are the nightly test machines identified? I went to look at my > machine's test results and couldn't find any (for a while) because a new > machine id had been set. I'd like to avoid creating new machine ids so > could you please indicate what factors lead to one run of nightly test > being viewed as a different machine?

On Fri, 3 Dec 2004, Jeff Cohen wrote: > It will have to be Morten. I can't get ltdl.c to compile. But wasn't > the whole point of doing platform-specific DynamicLibrary.cpps to get > rid of ltdl.c? ltdl.c is part of libtool that is supposed to BE the cross-platform dynamic linker interface. However, for platforms it doesn't really support, using custom code makes perfect

On Sun, 28 Nov 2004, Reid Spencer wrote: > The DynamicLibrary.cpp code is written and I believe it to be complete, > but it hasn't been tested much (at all). llvm-ld uses it to load its > plug-in optimization module. The implementation will use ltdl library > if its available, otherwise it tries to use dlopen/dlsym if they are > available, otherwise you get a compile time

On Thu, 19 May 2005, Reid Spencer wrote: > I forgot to remove some crud from the configure script and it caused > some of the nightly testers to fail last night. The problem has already > been fixed. Part of the problem was that it took 2 hours to get a commit > through to CVS last night and the nightly tester had already started by > that time. Something needs to be done about the

Reid Spencer <reid at x10sys.com> wrote: >> Currently we do little more than let programs use pthreads or some >> other threading library, but we do intend to eventually add first-class >> synchronization support to LLVM. This will develop as there is a need. > There _is_ a need :) .. let me know if I can help in this area, it is > one of the key things I need for

On Thu, 15 Jul 2004, Reid Spencer wrote: > > Another thing that is on my short list for 1.3 is to get as many .bc > > format changes out of the way as possible so the backwards compat code in > > the .bc reader is simpler. In particular, I would at least like to get > > placeholders for PR263 and maybe PR400. > > This I strongly agree with. We need to minimize impact

The XPL compiler produced the attached OneOfEach.bc file without error or warning from either LLVM or XPLC. However when I llvm-dis the file, I get: llvm-dis: Failed value look-up for name 'entry' The Bytecode Reader prints this out when it can't find the associated value for the name. Obviously I botched something in the XPL compiler but I would have thought the verified would

The only thing I can think of is that string.h is being #included and has different signatures for memcpy and strncpy. Possibly "char" is not signed on your machine (very unusual) or some of the parameters are declared as "const". Reid. On Wed, 2004-04-14 at 18:19, Eric Zimmerman wrote: > Chris, > > I'm fine with using JIT, but I'm trying to understand this

On Sun, 28 Nov 2004, Reid Spencer wrote: > FYI .. if you want to see how this works, check out > lib/System/DynamicLibrary.cpp and platform versions of it. Is it an option to use this interface now? How does libtool implement dlsym on darwin if not through the obvious interface? Can we just use whatever it uses? -Chris > On Sun, 2004-11-28 at 10:03, Reid Spencer wrote: > >

Hi, I would like to know how much effect these stoppoint calls have on the optimization of the bytecode? DOes insertion of debugging info cause opportunities for optimization (especially interprocedural dead code elimination and interprocedural constant propogation) to be reduced? The -g code is not very readable, so I am not able to confirm this by my own experiment. Thanks! Nikhil On Sat,

On Fri, 12 Nov 2004, Reid Spencer wrote: > On Fri, 2004-11-12 at 12:32, Chris Lattner wrote: > > > Perhaps the right way to handle this particular problem is to add the > > appropriate autoconf check to the llvm-test configure, then have the > > programs that need alloca use the detected value? > > Its already in the llvm configure which is inherited by llvm-test. If