similar to: [LLVMdev] disk space requirements on Windows

On Sat, Aug 21, 2004 at 04:15:49PM -0700, Jeff Cohen wrote: > I don't know if it's under cvs. It's the "getting started" page > (http://llvm.cs.uiuc.edu/docs/GettingStarted.html) in section "Getting > Started Quickly (A Summary)". But careful reading of the remainder of > the page does give the correct path. http://llvm.cs.uiuc.edu/docs/* is a copy of

On Wed, Mar 09, 2005 at 04:07:19PM -0800, xavier wrote: > I was trying to know if LLVM 1.5 works better with VC++ 2003 and to > what extent. This link: > > http://llvm.cs.uiuc.edu/releases/1.5/ > > Referred to in : http://llvm.cs.uiuc.edu/docs/ReleaseNotes.html > > Is broken LLVM 1.5 hasn't been released yet. :) This is the current work-in-progress that will be

Really JIT isn't my goal. I prefer use a native execution engine; and ok, I don't need save the generated Module so it ever lives in memory, so if LLVM doesn't generate relocatable code it's fine for me. About the reentrant lacks of LLVM, I can convert my own code - which build the Module - into a critical section so I think it is enough; but I need to know if several independent

On Fri, 20 Aug 2004 08:52:28 -0700 Reid Spencer <reid at x10sys.com> wrote: > Hi Jeff, > > On Fri, 2004-08-20 at 08:07, Jeff Cohen wrote: > > OK. I've built the front end without any heartaches, but I did > > encountered the following glitches: > > > > The documentation of --with-llvmgccdir is a bit ambiguous. I had to > > try several paths

Hi, Bill - On Wed, Jun 01, 2005 at 10:33:39AM -0400, Bill Wendling wrote: > What's the plan for support on Linux 64-bit machines? Is that actively > being worked on right now or is there a roadmap for doing this? Do you mean compiling on 64-bit Linux or generating code for 64-bits? As you can see here: http://llvm.cs.uiuc.edu/docs/GettingStarted.html#hardware

On Fri, Jan 07, 2005 at 12:04:04PM +0100, Francisco Puentes wrote: > Would be great if we append into the documentation several "patters" > to show how perform with LLVM. It would accelerate the learn curve for > beginners like me, avoiding basic errors and mistakes. If I reach a > good level with LLVM I can make these. I'm not sure if I understand what you mean. Are

> > Would be great if we append into the documentation several "patters" > > to show how perform with LLVM. It would accelerate the learn curve for > > beginners like me, avoiding basic errors and mistakes. If I reach a > > good level with LLVM I can make these. > > I'm not sure if I understand what you mean. Are you looking for an > "LLVM

Hi Misha, On 6/1/05, Misha Brukman <brukman at uiuc.edu> wrote: > On Wed, Jun 01, 2005 at 10:33:39AM -0400, Bill Wendling wrote: > > What's the plan for support on Linux 64-bit machines? Is that actively > > being worked on right now or is there a roadmap for doing this? > > Do you mean compiling on 64-bit Linux or generating code for 64-bits? > I meant

Karl, I think you meant to cc the llvmdev list on this. Thank you for a more detailed explanation, it's much clearer to me now. I agree that making the execution of .bc files more transparent would make it more useable as a stand-alone binary format on Unix-like systems and adding programmable support to changing the #! line would prevent much of user error involved in modifying the run

On Sat, 8 Jan 2005, Francisco Puentes wrote: >>> Would be great if we append into the documentation several "patters" >>> to show how perform with LLVM. It would accelerate the learn curve for >>> beginners like me, avoiding basic errors and mistakes. If I reach a >>> good level with LLVM I can make these. >> >> I'm not sure if I

On Thu, May 19, 2005 at 02:50:54PM -0700, Reid Spencer wrote: > Yeah, cygwin's a bit of a pig. To do a release build, just do: > make ENABLE_RELEASE=1 Actually, it's "make ENABLE_OPTIMIZED=1". Perhaps it should also allow ENABLE_RELEASE=1 as a synonym. Note that if you run ./configure the usual way, you *always* have to run "make ENABLE_OPTIMIZED=1" to build,

Constant *strcon==ConstantArray::get("Value : %d\n"); Sorry Typo. On Tue, 21 Dec 2004, Misha Brukman wrote: > On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > > I have this call instruction to printf inserted which is causing > > an assertion failure. Any pointers to where I am wrong : > > > > Function

Ms Brukman, Thanks for your reply.Just clarifying my question.I actually wanted to randomize the static layout of function code in the executable file.Sorry for writing in confusing manner. T Misha Brukman <brukman at cs.uiuc.edu> wrote: On Thu, Jun 02, 2005 at 02:12:22PM -0700, Tanu Sharma wrote: > By randomization of functions I mean the manner in whch they are > called , so

Sigh... take it up with Microsoft. On Fri, 24 Sep 2004 12:06:36 -0500 Misha Brukman <brukman at uiuc.edu> wrote: > On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > > (can't imagine it won't work). > > We prefer #include <cstdio>, since this is C++ after all. :) >

On Thu, Oct 07, 2004 at 06:46:18PM -0400, Shukang Zhou wrote: > Thanks Misha. I tried the "gcc -dM -E /tmp/file.c | grep __sparcv9" > but there was no output. Maybe this is the probelm, I do have > > CXX = g++ -mcpu=v9 > CC := gcc -mcpu=v9 > > in the Makefile.config. Do I need to add -m64 as well? Thanks. Just run the test that I mentioned before: > On Thu, 7

Hi Misha, Thanks for your answer I was doing this: ======================== BasicBlock *BBlock = new BasicBlock("entry", MyFunc); ... Value *Zero = ConstantSInt::get(Type::IntTy, 0); Value *UZero = ConstantUInt::get(Type::UIntTy, 0); MallocInst* mi = new MallocInst( STyStru ); mi->setName("tmp.0"); BBlock->getInstList().push_back( mi );

On Thu, Feb 17, 2005 at 11:39:27AM -0800, Reid Spencer wrote: > Actually, Misha, that won't work. Sorry, Reid, but I think it will, for the following reason: I don't really know what the -c (lowercase) option does, but install says it's ignored anyway, so that's irrelevant for GNU install. We're talking about the -C option (uppercase). > The -C option is used directly

> >>> Would be great if we append into the documentation several "patters" > >>> to show how perform with LLVM. It would accelerate the learn curve for > >>> beginners like me, avoiding basic errors and mistakes. If I reach a > >>> good level with LLVM I can make these. > >> > >> I'm not sure if I understand what you

On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > (can't imagine it won't work). We prefer #include <cstdio>, since this is C++ after all. :) -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

What's different about code that's been mem2reg'd from straight front end code, or anything that mem2reg hasn't been run on? PHINODES! It appears to be crashing when I try to cast a Value* that's really a BB* (from the PHInode operands) to a User*, insteresting since I am dyn_casting. I just caught this on cerr though (printing out what the Value* was each time). Let me