similar to: [LLVMdev] Some question on LLVM design

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

On Fri, 22 Oct 2004, Marc Ordinas i Llopis wrote: > Hi everybody, Hi! > 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 Very cool! > have read most of the llvmdev archives, and I'm aware that some things > are 'planned' but not implemented yet. We are willing to

Misha Brukman wrote: > >>1. Opcodes and intrinsics >> > That's not really correct. The intrinsics such as llvm.frameaddress and > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > the intrinsics is specifically machine-dependent, and LLVM (and its > opcodes) are machine-independent, so there is no valid interchange of > these intrinsics

Hi all, Sorry if this is obvious. I'm trying to link LLVM-generated code with LLVM itself, and don't know how to do it. Just as a little test, I've tried compiling the example HowToUseJIT.cpp using llvm-g++, but I get tons of errors. Is there an easy way of doing this? Has anyone tried it before? Thanks, Marc Ordinas i Llopis | Tragnarion Studios

Thanks all for the fast answers, I'm certainly understanding LLVM better. Some more comments below: Chris Lattner wrote: >>Couldn't the front-end just produce stores/volatile stores and then a >>compilation pass transform them into a write-barrier if necessary? > > > Sortof. The problem with this is that (without gcwrite) there is no way > to identify the

Excuse the long post, Chris Lattner wrote: > On Fri, 11 Mar 2005, Marc Ordinas i Llopis wrote: > >> Sorry if this is obvious. >> I'm trying to link LLVM-generated code with LLVM itself, and don't >> know how to do it. Just as a little test, I've tried compiling the >> example HowToUseJIT.cpp using llvm-g++, but I get tons of errors. >> >>

On Mon, 14 Mar 2005, Marc Ordinas i Llopis wrote: > Finally, I tried first generating the .o (bytecode) file, and then linking > got me the same result. > > So, I'm really stuck here. Is there a way of linking LLVM-produced code with > LLVM? Has anyone tried it before? I guess I don't really understand what your goal is. Currently our support for transparently mixing

On Fri, 11 Mar 2005, Marc Ordinas i Llopis wrote: > Sorry if this is obvious. > I'm trying to link LLVM-generated code with LLVM itself, and don't know how > to do it. Just as a little test, I've tried compiling the example > HowToUseJIT.cpp using llvm-g++, but I get tons of errors. > > Is there an easy way of doing this? Has anyone tried it before? What sort of

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

Gordon Henriksen wrote: > > The "runtime interface" is a historical artifact. LLVM does not impose > a runtime library on its users. I wouldn't have a problem deleting all > mention of it, since LLVM does not impose a contract on the runtime. > Excellent, I found it somewhat unhelpful! >> The semantics of llvm.gcroot are vague: >> "At

Hi, I realise this might be a bit controversial ;) Suppose I am writing a VM (such as VMKit), or a VM toolkit, and I want to add a generational GC. If I want to use the llvm.gcwrite intrinsic for my write barrier then I need to write a GC and then implement for each and *every* backend the gcwrite intrinsic for my write barrier. Now, if I don't use the intrinsic, I need to write my write

Mark Shannon wrote: > Jon Harrop wrote: >> On Thursday 26 February 2009 17:25:56 Chris Lattner wrote: >>> In my ideal world, this would be: >>> >>> 1. Subsystems [with clean interfaces] for thread management, >>> finalization, object model interactions, etc. >>> 2. Within different high-level designs (e.g. copying, mark/sweep, etc) >>>

Gordon Henriksen wrote: > Hi Mark, > > I don't think anyone will dispute that it's easier to hack up a shadow > stack (or plug into a conservative collector) to get up and running > with GC. That is absolutely the route to go if portability trumps > performance. Why? LLVM is all about portability AND performance. > > If you review the mailing list history,

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Feb 27, 2009, at 12:56, Mark Shannon wrote: > Gordon Henriksen wrote: > >> The ultimate endgoal is to support schemes with still-lower >> execution overhead. The next step for LLVM GC would be elimination >> of the reload penalty for using GC intrinsics with a copying >> collector. This, again, requires that the code generator perform >> bookkeeping

On 2009-03-01, at 05:41, Mark Shannon wrote: > Gordon Henriksen wrote: > >>> The semantics of llvm.gcroot are vague: "At compile-time, the code >>> generator generates information to allow the runtime to find the >>> pointer at GC safe points." >>> >>> Vague, ill-specified interfaces are worse than none. >> >>

Hi Hal, Thanks for the guidance. I hope you don’t mind that I’m adding LLVMDev to this e-mail thread, as it seems as though it may be of general interest. I agree that duplicating the FP opcodes should be our goal. I just wasn’t sure that was entirely possible. I’ll try adding implicit defs in the way you’ve suggested, but I’m concerned that there may be code that relies on the TII for that

Hi Bill, Thanks a lot for your response.But my problem still remains.The thing is i am having a data type std::vector<Value*> as i am checking for the variables in Store Instructions and Malloc Instructions.For store the case is straightforward as discussed earlier.I want the same Value* variable for malloc inst as well. bcos i cannot have a different set for only instructions. can there be

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When