similar to: [LLVMdev] Assignment instruction.

Thanks for the fast reply. I'll do as you suggested, and create my own identity instructions with "add" for int's and "getelementptr" for pointers. , Tobias On Thu, 17 Jun 2004, Misha Brukman wrote: > On Thu, Jun 17, 2004 at 05:09:30PM +0200, Tobias Nurmiranta wrote: > > A small thing I miss in the intermediate representation is a simple > > assignment

On Thu, Jun 17, 2004 at 05:09:30PM +0200, Tobias Nurmiranta wrote: > A small thing I miss in the intermediate representation is a simple > assignment instruction, like: > > %x = uint 3 > or: > %x = uint %y > > It would simplify the implementation of frontends, I think. Neither of these is necessary, and adding new instructions means every transformation has to handle

On Thu, 17 Jun 2004, Tobias Nurmiranta wrote: > > Thanks for the fast reply. I'll do as you suggested, and create my own > identity instructions with "add" for int's and "getelementptr" for > pointers. Another thing to point out is that this might only be happening because your front-end is attempting to generate SSA. In general, we don't recommend

Hi, Yiping! I am not sure of the answer to your question, but I am forwarding it to the LLVMdev list where I am sure someone will be able to answer you. Please send development questions directly to LLVMdev and you will get a response quicker, as it is read by many LLVM developers. ----- Forwarded message from Yiping Fan <fanyp at cs.ucla.edu> ----- Date: Mon, 31 Oct 2005 17:20:24 -0800

Hi! Hmm, ok. I'm using the 1.2 release. Found out that it worked when using long to index getelementptr, but not when using uint, int or ulong. But then I'll try with the CVS code instead. Thank you. , Tobias On Sat, 12 Jun 2004, Reid Spencer wrote: > Hi Tobias, > > I tried your test program on the latest CVS code. Everything worked > fine. > > Can you tell me which

Hi, I'm trying to compile and run the following code-snippet: implementation uint %fie(uint* %x) { %e = getelementptr uint* %x, int 1 ; %f = load uint* %e ret uint 3 } int %main(int %argc, sbyte** %argv) { %z = malloc uint, uint 10 %g = call uint %fie(uint* %z) ret int 0 } But the getelementptr instruction gives a segmentation fault. Have I misunderstood its use? I

Hello! I am having trouble with identifiers: %tmpFunction = load int ()** %puts_kernelPTR ... %tmpFunction = load int ()** %puts_kernelPTR generates Redefinition of value named 'tmpFunction' in the 'int () *' type plane! Is it not allowed to reuse variables? Is there some way to do it? Anders ---------------------------------------------------------------- Anders

Hi Tobias, I tried your test program on the latest CVS code. Everything worked fine. Can you tell me which version of LLVM you're using? Reid. On Sat, 2004-06-12 at 08:26, Tobias Nurmiranta wrote: > Hi, > > I'm trying to compile and run the following code-snippet: > > implementation > > uint %fie(uint* %x) { > %e = getelementptr uint* %x, int 1 > ;

Hi, Given these C instructions: ============================== struct stru { struct stru *Next; }; struct list *NewStru = malloc ( sizeof ( struct stru ) ); struct list *tmp.3; ... tmp.3 = NewStru->Next; ============================== LLVM generates something like this: %tmp.0 = malloc %struct.stru ; <%struct.stru*> %tmp.3 = getelementptr %struct.stru* %tmp.0, int 0, uint 1 ;

Hi again, Which optimization/flag to "opt" should I use to optimize away these alloca's? In most cases it is more convenient for me to use SSA-registers, but for example if-statements and some others, it is nicer to use alloca. Thanks for the advice. , Tobias On Thu, 17 Jun 2004, Chris Lattner wrote: > On Thu, 17 Jun 2004, Tobias Nurmiranta wrote: > > > > Thanks for

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 );

Hi, I'm thinking out loud, please give me some feedback. Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are implemented as: llvm.gcread(sbyte** object, uint offset) llvm.gcwrite(sbyte* data, sbyte** object, uint offset) Where you also have the offset into the object. In this way the GC would know where the header of the object we are reading/writing to is. Also

On Wed, May 05, 2004 at 03:35:46PM +0200, Anders Alexandersson wrote: > %tmpFunction = load int ()** %puts_kernelPTR > ... > %tmpFunction = load int ()** %puts_kernelPTR > > generates > > Redefinition of value named 'tmpFunction' in the 'int () *' type plane! > > Is it not allowed to reuse variables? Is there some way to do it? LLVM uses the Static

Hi, This is regarding the backend for garbage collection. My problem might be related to some strange memory fault created by my frontend, but I'll try here to get some feedback. For some strange reason I get segmentation fault in process_pointer in semispace.c (I've implemented a small collector, hopefully :). The fault occurs when I do: printf("process_root[0x%p] = 0x%p\n",

On Tue, May 31, 2005 at 08:42:26AM -0500, Patrick Meredith wrote: > Currently, my way around this was to go into Instruction.h and make > setParent() public. I hope there is a better way? You shouldn't be modifying the API like this ... > When one moves an instruction from one BasicBlock to another, the > instruction continues to believe that its parent is the original >

Reid Spencer wrote: > Its certainly possible to generate .ll files but its probably about the > same amount of work to use the LLVM API and there are significant speed > and validity benefits to doing so. Does this mean that LLVM is moving away from the idea of a truly abstract IR language, to being a set of development libraries for use by build-time-dependent frontends?

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > [1] I'm kind of newbie of cvs, but I did: > "cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm diff llvm > gcpatch" That patch is well formed. You did exactly the right thing. :) > Ok, a patch[1] is attached. I didn't care to coerce the offset, since I > assume that it is an uint, but maybe I should?

Dear all, Recently I've wanted to add support for threads to LLVM (motivated by OpenMP, more or less), but before jumping in and implementing anything, I thought it might be a good idea to describe what I have in mind and ask for comments. Hence this email - if anyone has any comments, I'd be very glad to hear them. WHAT I'M PROPOSING: The addition of two instructions - fork

Hi, Regarding llvm.gcroot, do I have to allocate stack-space for all pointers in a function? Right now I mostly use SSA-variables, and let llvm's register allocation allocate stack-space when needed. Also, what happens when I run the mem2reg pass, does it handle llvm.gcroot's that are moved from stack to registers? I'm thinking along the lines, that should one not use llvm.gcroot on

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