similar to: [LLVMdev] Getting To Native Code

Kewl Beans! You're heading right where I need LLVM to go :) Details ... On Wed, 2003-11-12 at 07:22, John Criswell wrote: > Funny you should mention that; getting a C library compiled to LLVM > code is one of the tasks on my plate. :) Good. If I can help, please let me know. > You are correct that the LLVM assembly language cannot accept native > assembly instructions

Reid Spencer wrote: > Suppose I wanted to, say, write glibc for LLVM (fat chance! :) I would > need at some point to write (hopefully a small amount) of native code > to, say, access specific registers, handle interrupts, or generate > operating system traps. Funny you should mention that; getting a C library compiled to LLVM code is one of the tasks on my plate. :) > >

I'm CC'ing the llvm-dev list because other people are more knowledgeable about the bytecode format/encoding than I am. Please follow-up the replies to the list. On Wed, Oct 20, 2004 at 11:27:53AM -0700, Yiping Fan wrote: > We also want to extend the llvm instructions/intrinsic > functions/types/passes to support our high-level synthesis for > hardware. First of all, we want to

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > 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

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 Fri, 14 Apr 2006 03:25:39 +0200 Oscar Fuentes <oscarfv at telefonica.net> wrote: ... > Simon, > > With a fresh CVS checkout, I've tried your test case on Windows/VC++ > and it works ok. Too bad that I have not access to a Linux machine > right now. I'll like to see what's wrong with your test case. > > What you get from running the test case under gdb

I have just begun investigating LLVM because it seems like it might be an ideal tool for building tools for playing with software. However, my current project is related to parallel programming on shared memory multiprocessor systems, so I need thread support. As far as I can tell, LLVM currently has no intrinsic support for threads, is this correct? I saw the bug that indicates that

On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >>> >>> New method of emitting object code is ok for me. But it is still >>> experimental, isn't it? >> >> Yes. > > Thank you for answers! > > Now there is a way to implement what I'd like to. But it would be MUCH > better if LLVMTargetMachine::addPassesToEmitFile could take

Currently, Structure layout is left to targets, which implement them according to the ABI of that platform. While this is fine for most structures, it makes packed structures very ugly. All fields in a packed type must be converted to byte arrays with casts to access fields, which bloats accesses and obsfucates the types. First class support for packed types would clean up the generated code

Hi, Where can I find the main function of llvm compiler in the source file? Thanks! -- Shuhan

Hello (again)! I fixed most of the system and the following projects compile now: * Analysis * AsmParser * Bytecode * CBeckend * Codegen * ExecutionEngine * Support * System * TableGen * Target * Transforms * VMCore I would like to compile at least x86 target as well as Fibonacci example (to test if it really works). In order to do so, I may need some hints: 1) How to generate

Chris Lattner wrote: > On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: > >>>> What exactly is expected to be coming? Will it be the same way MachO is >>>> currently implemented but with some flexibility to supply my own class >>>> to do actual object output? Or just a return of old ObjectCodeEmitter? >>> We're integrating a full assembler

Hi, I want to implement a new intrinsic in llvm that will denote a parallel section within a function. I followed the documentation for extending llvm (http://llvm.org/docs/ExtendingLLVM.html) but there is something about the working mechanism that is not clear for me. 1. Why do we have to add support for the C backend? Is this only necessary to transform the llvm assembly (bytecode) into C code

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> New method of emitting object code is ok for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better if

Hi Andrew, Andrew Lenharth wrote: > On 4/2/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > >> Hi everyone, >> >> Currently, when declaring a va_list in llvm, one only needs to do: >> >> %ap = alloca i8 * (Reference : llvm/docs/LangRef.html#int_varargs) >> > > This example is x86 specific. alpha allocas an {sbyte*, int}

Yeah. We need to have more extra fields in the instruction. Fo example, during high-level synthesis, we must schedule an instruction to a certain control step (or cycle), and bind it to be execute on a certain functional unit, etc. Besides the in-memory exchange of the information, we also want on-disk exchange. That introduces the write-out/parse-in problem. Thanks ----- Original Message -----

Prof. Adve, The idea is to develop a memory model where each byte is extended with 3 extra bits. Programs are running on this memory model. Load/store instructions, including those in LibC functions, needs to deal with the extra bits in a certain manner. Basically, my questions are: (1) Is it feasible to implement the memory model where each byte is extended with 3 extra bit? (2) Is there a

Hi, I currently write a tool to parse the LLVM bytecode file (.bc file). So I have some very basic questions: - First, about the Abbreviation ID ( "0"=END_BLOCK, "1"=ENTER_SUBBLOCK...): how to read these ID from the file stream ? I mean, I don't know, how many bit length they are. It doesn't exist on the document. - Second, how is the order to read the bytecode ? For

shding at mtu.edu wrote: > Hi, > Where can I find the main function of llvm compiler in the source file? > Thanks! Well, there's a loaded question. :) It depends on "which" compiler you mean. If you're talking about the llvm-gcc and llvm-g++ compilers (C/C++ to LLVM) then they are in the downloadable tarballs available here: http://llvm.cs.uiuc.edu/releases/. You