similar to: [LLVMdev] Projects Cleanup

On Tue, 17 Aug 2004, Reid Spencer wrote: > On second thought, the makefiles don't (easily) allow this do they? You can > only build one program per directory. Were you suggesting that you wanted me to > move the entire directories under a "small examples" directory? You're right. The simples way to do this would be to have: projects/ SmallExamples/

On second thought, the makefiles don't (easily) allow this do they? You can only build one program per directory. Were you suggesting that you wanted me to move the entire directories under a "small examples" directory? Reid. Chris Lattner wrote: > On Tue, 17 Aug 2004, Reid Spencer wrote: > > >>That's pretty cute actually. Do you want this

On Tue, 17 Aug 2004, Reid Spencer wrote: > That's pretty cute actually. Do you want this "brilliant" :) example in the cvs > repository? I'd be happy to put it in. Here's an idea: how about we take the ModuleMaker, Valery's previous example, and this one and put them all in one "small examples" project? -Chris > Valery A.Khamenya wrote: > >

Valery, That's pretty cute actually. Do you want this "brilliant" :) example in the cvs repository? I'd be happy to put it in. Reid. Valery A.Khamenya wrote: > Hi LLVMers, > > the example attached I have used to prove that JIT and some visible > optimizations are really invoked. > > Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 >

llvm-bounces at cs.uiuc.edu wrote: > > ------------------------------------------------------------------------ > > Subject: > Fw: (by sospeng at tom.com)something is wrong , when compiling llvm on debian > From: > "4" <sospeng at tom.com> > Date: > Mon, 29 Aug 2005 20:05:46 +0800 (CST) > To: > llvmdev at cs.uiuc.edu > > To: > llvmdev at

I constructed an LLVM 2.7 VS solution with cmake, but it has 66 projects: ALL_BUILD, ".\ALL_BUILD.vcproj" BrainF, "examples\BrainF\BrainF.vcproj" Fibonacci, "examples\Fibonacci\Fibonacci.vcproj" FileCheck, "utils\FileCheck\FileCheck.vcproj" HowToUseJIT,

One thing that helps me understand complex software is a dependency graph. I found an LLVM dependency graph at https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_16/docs/UsingLibraries.html#dependencies but it's really messy and hard to follow. From that graph I made a cleaner graph by hand (attached)... sorry about the fax-quality scan. But I have some questions about it... -

On Wed, 18 Aug 2004, Valery A.Khamenya wrote: > the example attached I have used to prove that JIT and some visible > optimizations are really invoked. > > Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 > on my Athlon XP 1500. Cool! Hey Valery, before we add this to the CVS repo, can you take a look at some of the changes I made to your HowToUseJIT example and

Valery, I agree that there could be more examples of JIT-based interpreters, and I like your idea. When can you have it ready? :) Reid. On Sun, 2004-08-08 at 13:11, Valery A.Khamenya wrote: > Hi all, > > I think there is still too few docs/samples for those, > who'd like to write JIT-based interpreters. > > Today, the real examples to learn from are rather: > > -

Hi all, (thanks to Reid, who gave nice advice) the fibonacci function code works now. Please find attached file. but... the performance is adequate, say, for byte-code interpretation mode and not for optimized JITing. fibonacci function of 35 from attached file is more then 100 times slower then the following code compiled with "gcc -O2" : ----------- #include <iostream> int

Hi LLVMers, the example attached I have used to prove that JIT and some visible optimizations are really invoked. Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 on my Athlon XP 1500. Nice. P.S. guys, no fears, I don't plan to flood the cvs repository with my "brilliant" examples ;) --- Valery A.Khamenya -------------- next part -------------- An

On Sat, 14 Aug 2004, Valery A.Khamenya wrote: > (thanks to Reid, who gave nice advice) the fibonacci function code > works now. Please find attached file. > > but... the performance is adequate, say, for byte-code > interpretation mode and not for optimized JITing. > fibonacci function of 35 from attached file is more > then 100 times slower then the following code compiled

Hi all, I think there is still too few docs/samples for those, who'd like to write JIT-based interpreters. Today, the real examples to learn from are rather: - lli.cpp - ModuleMaker.cpp - Stacker which is still unfortunatelly not that much about JITing :( Well, what I am going to sell: What about very small JIT-based example similar to ModuleMaker? I mean example, where, say, two

Hi again, I wrote: > > I would like to test but the I modigied the configure to make > > unknown = OpenBSD and Unix > > Have you looked at ./config.log. ./configure creates this as it runs > as a trace of the path it took through ./configure. Work backwards > from the end to find out what it didn't like. I remember SourceForge's compile farm has an OpenBSD x86

I just added __OpenBSD__ everywhere __FreeBSD__ was being tested (there were about a dozen places). I suspect we'll have to add one for NetBSD also one day (even DragonflyBSD?). INT8_MAX and friends ought to be declared by <stdint.h>. It is on FreeBSD. Ralph Corderoy wrote: >Hi again, > >I wrote: > > >>>I would like to test but the I modigied the

Hi all, here comes the patch for the first wave of Use class size reduction. I have split it into 3 files, corresponding to - header changes - implementation changes - applications This at the moment does not contain the description how the size of the Use class will be reduced from 16 to 12 bytes, I am going to send that in a separate patch. This wave primarily consists of changes that are

Thanks for the information I am trying to use one of your examples for recursive data structures: ========================= PATypeHolder StructTy = OpaqueType::get(); std::vector<const Type*> Elts; Elts.push_back(PointerType::get(StructTy)); Elts.push_back(PointerType::get(Type::SByteTy)); StructType *NewSTy = StructType::get(Elts); // At this point, NewSTy = "{ opaque*, sbyte*

Hi Valery, Valery A.Khamenya wrote: >>To me this appears more as an algorithmic design issue, this function >>could be rewritten in "continuation passing style", and each >>continuation could be distributed by a load-balancing strategy to the >>computers sharing CPU resources. Using mechanisms such as "futures" (as >>in Mozart) allows to do

I'll Check it out.. is it in the CVS or the release yet.. or how do I apply a patch to it... thanks much for the update.. I'll feel better about the whole thing..OpenBSD is really nice with the pro-police stack and would like to see an alternative to the GCC only compiler chain of tools especially as it is based on a somewhat archaic optiminzation backend and procedural stuff is pretty

On Tue, 15 Mar 2005, xavier wrote: > Thanks for the information > I am trying to use one of your examples for recursive data structures: > > ========================= > PATypeHolder StructTy = OpaqueType::get(); > std::vector<const Type*> Elts; > Elts.push_back(PointerType::get(StructTy)); > Elts.push_back(PointerType::get(Type::SByteTy)); > StructType *NewSTy =