similar to: [LLVMdev] 9 Ideas To Better Support Source Language Developers

On Tue, 6 Jan 2004, Reid Spencer wrote: > A while back I promised to provide some feedback on useful extensions to > LLVM to better support source language writers (i.e. those _using_ LLVM, > not developing it). Below is a list of the ideas I've come up with so > far. Cool! Ideas are alway welcome! > If you respond to this, please respond to each item in a separate >

On Wed, 2004-01-07 at 11:12, Chris Lattner wrote: > > ------------------------------------------------------------------ > > 1. Definition Import > > Source languages are likely to create lots of named type and value > > definitions for the memory objects the language manipulates. Redefining > > these in every module produces byte code bloat. It would be very useful

On Sun, 2003-11-16 at 13:01, Vipin Gokhale wrote: > While on the subject of annotating bytecode with analysis info, could I > entice someone to also think about carrying other types of source-level > annotations through into bytecode ? This is particularly useful for > situations where one wants to use LLVM infrastructure for its > whole-program optimization capabilities,

The XPL compiler produced the attached OneOfEach.bc file without error or warning from either LLVM or XPLC. However when I llvm-dis the file, I get: llvm-dis: Failed value look-up for name 'entry' The Bytecode Reader prints this out when it can't find the associated value for the name. Obviously I botched something in the XPL compiler but I would have thought the verified would

Chris Lattner wrote: > On Sun, 16 Nov 2003, Reid Spencer wrote: > > >>On Sun, 2003-11-16 at 11:17, Chris Lattner wrote: >> >> >>>No, it's all or nothing. Once linked, they cannot be seperated (easily). >>>However, especially when using the JIT, there is little overhead for >>>running a gigantic program that only has 1% of the functions

> The point here is that XPL needs to keep track of what a given variable > represents at the source level. If the compiler sees a map that is > initially small it might represent it in LLVM assembly as a vector of > pairs. Later on, it gets optimized into being a hash table. In order to > do that and keep track of things, I need to know that the vector of > pairs is

On Sun, 2003-11-16 at 17:13, Chris Lattner wrote: > > The point here is that XPL needs to keep track of what a given variable > > represents at the source level. If the compiler sees a map that is > > initially small it might represent it in LLVM assembly as a vector of > > pairs. Later on, it gets optimized into being a hash table. In order to > > do that and keep

On Sun, 16 Nov 2003, Reid Spencer wrote: > On Sun, 2003-11-16 at 11:17, Chris Lattner wrote: > > > No, it's all or nothing. Once linked, they cannot be seperated (easily). > > However, especially when using the JIT, there is little overhead for > > running a gigantic program that only has 1% of the functions in it ever > > executed... > > Perhaps in the

On Fri, 2004-03-26 at 14:57, Chris Lattner wrote: > On Fri, 26 Mar 2004, Reid Spencer wrote: > > > Would people other than myself find it useful to have a standardized > > extension framework for LLVM? I'm thinking of something that would allow > > new LLVM instructions, fundamental types, structured types, etc. This > > would require significant work to allow

I tried asking in another thread this week, but I'm not sure people saw the actual subject of the question. Does anyone know where to find documentation of xPL, the home automation interface? Specifically for integrating it with Asterisk. xPL is part of Trixbox, so it's being used, but where is some expertise for using it without Trixbox? -- (C) Matthew Rubenstein

On Sun, 2003-11-16 at 11:17, Chris Lattner wrote: > No, it's all or nothing. Once linked, they cannot be seperated (easily). > However, especially when using the JIT, there is little overhead for > running a gigantic program that only has 1% of the functions in it ever > executed... Perhaps in the general case, but what if its running on an embedded system and the "gigantic

My $0.02 worth on this topic .. I'm also interested in distributed computing as XPL/XPS will support it. However, I find it unreasonable to expect LLVM to provide any features in this area. In order to do anything meaningful, LLVM would have to have some kind of awareness of networks (typically an operating system concern). That seems at odds with the "low level" principles of

On Fri, 26 Mar 2004, Reid Spencer wrote: > Would people other than myself find it useful to have a standardized > extension framework for LLVM? I'm thinking of something that would allow > new LLVM instructions, fundamental types, structured types, etc. This > would require significant work to allow the various pieces of LLVM > (assembler, disassembler, runtime, JIT,

On Wed, 7 Jan 2004, Valery A.Khamenya wrote: > Wednesday, January 7, 2004, 9:37:19 PM, you wrote: > > Well, Chris, let's forget about traditions (finally LLVM is > tradition-breaking thing!). At which level the optimization like i've > meant *should* be implemented?.. Ok, I thought you were concerned about LLVM breaking the _correctness_ of distributed programs, sorry. :)

Hello, After a fair amount of research and work, I have put together a concrete proposal for LLVM representations of atomic operations and synchronization constructs. These aim to provide the minimal functionality in the IR for representing the hardware constructs that threading libraries and parallel programming rely on. http://chandlerc.net/llvm_atomics.html While I am no expert on the

The SymbolTable is a map of Type* to a map of names to Value*. This means that in order to lookup something by name you first have to know what type it is. For the basic types this is fine because you generally always know which basic type you're after. But, for derived types, this can be quite complicated. It isn't always possible to know the exact type. In XPL, types are just names.

I was going to wait to bring this up but since the topic has been addressed ... Would people other than myself find it useful to have a standardized extension framework for LLVM? I'm thinking of something that would allow new LLVM instructions, fundamental types, structured types, etc. This would require significant work to allow the various pieces of LLVM (assembler, disassembler, runtime,

On Sun, 28 Mar 2004, Reid Spencer wrote: > The XPL compiler produced the attached OneOfEach.bc file without error > or warning from either LLVM or XPLC. However when I llvm-dis the file, I > get: > > llvm-dis: Failed value look-up for name 'entry' I'm guessing that 'entry' is a basic block? > The Bytecode Reader prints this out when it can't find the

I just found "entry". Its the name I gave a basic block at the start of the function (name was hard coded in the compiler, not the source). The issue here is probably that the block doesn't have a terminating instruction. However, that fact used to be caught well by the validator. Furthermore, the output from the byte code reader is a little confusing given the source of the

One of the things I use heavily in conjunction with LLVM is libxml2. This provides the XML parsing (amongst other things) that I need for my XPL source language. Since XPL supports XML parsing at runtime, I would like to be able to compile libxml2 to bytecode and have it undergo optimization as well. libxml2 is "C" code, well written and reasonably large. I'm wondering if it would