similar to: [LLVMdev] Threading support

Johan, You are correct that today LLVM doesn't handle multi-threaded programs. However, I believe Misha is working on this now (correct me if I'm wrong Misha). To file a bugzilla on this would be a little redundant. Its a well-known issue and one that is being worked on. Reid. Johan Walles wrote: > Hi! > > I've read in the mailing list archives that LLVM isn't able

Hi, I'm currently implementing some optimization passes for LLVM and I came across a problem. I'm new to LLVM so if this question has been asked before please kindly tell me where can I find the answer. There are 2 types of AllocationInst - Alloca and Malloc. But most of the time from the compiled byte code I can only find the Alloca statement (actually I never come across a

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 Sat, 23 Oct 2004, Misha Brukman wrote: > > A possible view of intrinsics could be "operations that don't depend > > on the target architecture, but instead on the language runtime". But > > then wouldn't malloc/free be intrinsics? > > Good question. Due to the amount of pointer/data analysis in LLVM, it > is often necessary to consider memory

On Fri, Oct 22, 2004 at 03:18:00PM +0200, Marc Ordinas i Llopis wrote: > I'm currently looking at LLVM as a possible back-end to a dynamic > programming system (in the tradition of Smalltalk) we are developing. Neat! > I have read most of the llvmdev archives, and I'm aware that some > things are 'planned' but not implemented yet. We are willing to > contribute

Hi all, I am working on some old code which was compiled against llvm-2.5. Anyway, in some places I, AllocationInst is used (e.g. to ensure the instruction's type). Even in your current documentation (http://llvm.org/docs/ProgrammersManual.html), I found an example that uses this instruction. If I got it correctly, this istruction (AllocationInst) has been removed from llvm instruction set.

On Sun, Oct 24, 2004 at 01:17:19AM -0500, Chris Lattner wrote: > The one advantage that mallocinst has over using an intrnisic is that > instructions can have different return values in various parts of the > program (e.g., you can write 'malloc int' instead of > '(int*)malloc(4)'). OK, then you could say that the *real* advantage of the malloc/alloca instructions is

Hamid 2C wrote: > Hi all, > > I am working on some old code which was compiled against llvm-2.5. > Anyway, in some places I, AllocationInst is used (e.g. to ensure the > instruction's type). Even in your current documentation > (http://llvm.org/docs/ProgrammersManual.html), I found an example that > uses this instruction. > If I got it correctly, this istruction

Hi everybody, I'm currently looking at LLVM as a possible back-end to a dynamic programming system (in the tradition of Smalltalk) we are developing. I have read most of the llvmdev archives, and I'm aware that some things are 'planned' but not implemented yet. We are willing to contribute the code we'll need for our project, but before I can start coding I'll have to

Actually, Misha, that won't work. The -C option is used directly in docs/Makefile. So the change will have to go into docs/Makefile. Either that or upgrade install to version 5. Reid. On Thu, 2005-02-17 at 11:33, Misha Brukman wrote: > On Thu, Feb 17, 2005 at 01:21:20PM -0600, Feng Chen wrote: > > llvm[1]: Installing HTML documentation > >

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 that has to do with address.I wish to randomize the order > of calls made to functions when a program is run. How would you "randomize the order of calls made to functions when a program is run" without changing the semantics of the

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

By randomization of functions I mean the manner in whch they are called , so that has to do with address.I wish to randomize the order of calls made to functions when a program is run. Reid Spencer <reid at x10sys.com> wrote:Can you explain a little bit more about what you mean by "randomize" functions or global variables? What aspect of them do you want to randomize? Their

On Wed, Jun 23, 2004 at 03:50:09PM -0500, Patrick Meredith wrote: > MetaSplit is an anlysis I just finished writing. It doesn't alter > anything, all it does is build a set of "program instructions". For > some reason even though if I run it with any other combination of > passes I've found, anytime I run it with mem2reg I get a seg fault in > dyn_cast!

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. Shukang On Thu, 7 Oct 2004, Misha Brukman wrote: > Is your compiler configured to define __sparcv9 when it compiles? > The following should tell

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

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

On Wed, 23 Jun 2004, Patrick Meredith wrote: > 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! Yup, front-ends generally don't produce SSA form. :) > It appears to be crashing when I try to cast a Value* that's really a > BB* (from the PHInode operands) to a User*,

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

Here's the patch to Signals.cpp. assuming that stdio.h is acceptable (can't imagine it won't work). On Fri, 24 Sep 2004 09:29:05 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > Uh... this may be a silly question, but why can't you include <stdio.h>? > It'd be much better than <iostream>. > > Anyway, I think I'll try this weekend to come