similar to: [LLVMdev] Can't Figure Out My Error :(

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

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

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. As I get more of XPL's compiler done, I'll start diving into each of the these areas. I'm posting early in the hopes that discussion will bear some fruit. In

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

Sorry about the lengthy post, I've searched high and lo for information on how to do this but now I need your help... ======== Brief intro on problem and requirements =========== I'm hoping to use Asterisk in a Home environment where I'd like to replace the current non-PC Answering Machine, and get added benefits such as IVR, and text to speeach, for Home Automation purposes.

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,

I am using centos 4.4 server cd ,when I am trying to compile zaptel 1.4.2 ,the following error appears >From where I can get the missing rpms .or kernel source grep: /lib/modules/2.6.18-8.el5/build/include/linux/autoconf.h: No such file or directory grep: /lib/modules/2.6.18-8.el5/build/include/linux/autoconf.h: No such file or directory make[1]: Entering directory

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.

In the following IR module: – define i8 @foo() #0 { entry: %call0 = call i8 @bar() ret i8 %call0 } declare i8 @bar() #1 – @bar() gets marked as its own user in top-of-tree LLVM. I patched the Verifier to check it (but didn’t commit the patch): – Index: lib/IR/Verifier.cpp =================================================================== --- lib/IR/Verifier.cpp (revision 203468) +++

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

Hello all, I am willing to do "eliminating the void type" project. Is there anyone working on it? === Overview === The general concept is to replaced void with {}. And 'ret void' is a synonym of 'ret {} {}.' === Further Implementation Details === 1. Deleting VoidTyID 2. Deleting LLVMVoidTypeKind (one-to-one relation between VoidTyID and LLVMVoidTypeKind) 3. Use

Hi Mitnick, > === Overview === > > The general concept is to replaced void with {}. And 'ret void' is a synonym of > 'ret {} {}.' in a sense the concept is just to delete void and not to replace it with anything in particular. Of course front-ends (clang, dragonegg) need to produce something instead of void, and {} is an example of what they might produce, but they

Thank you Chris, for your hint, but I am still too stupid. I tried two versions asm_arguments.push_back(Type::VoidTy); FunctionType *asm_type = FunctionType::get(Type::VoidTy, asm_arguments, false); Alternatively FunctionType *asm_type = FunctionType::get(Type::VoidTy, std::vector<const Type*>(), false); . Can you give me a snippet of example code, or somebody else?

Hi, The checking about that if this is a terminator that it is at the end of the block has been applied twice (bellow). One is at Verifier::visitInstruction, and the other is at Verifier::visitTerminatorInst. Since visitInstruction is called when visiting each instruction, the checking at visitTerminatorInst seems redundant to me. Did I miss any case? void Verifier::visitInstruction(Instruction

On 5/7/12 10:36 AM, Duncan Sands wrote: > Hi Mitnick, > >> === Overview === >> >> The general concept is to replaced void with {}. And 'ret void' is a synonym of >> 'ret {} {}.' > in a sense the concept is just to delete void and not to replace it with > anything in particular. Of course front-ends (clang, dragonegg) need to produce >

Hi, I' am trying to insert an InlineAsm Instruction in my pass, which FunctionType do I need for Inlineasm? If I understand it right, I need a call instruction to insert the new produced InlineAsm? Thanks for help, Michael for (BasicBlock::iterator bi = i->begin(), be = i->end(); bi != be; ++bi){ std::vector<const Type*> asm_arguments;

On Jul 31, 2009, at 10:24 AM, Michael Graumann wrote: > Hi, > I’ am trying to insert an InlineAsm Instruction in my pass, which > FunctionType do I need for Inlineasm? > If I understand it right, I need a call instruction to insert the > new produced InlineAsm? > > Thanks for help Inline asm works like a "callee". So for: call void asm sideeffect

On Jul 31, 2009, at 5:04 PM, Michael Graumann wrote: > Thank you Chris, > for your hint, but I am still too stupid. I tried two versions > > asm_arguments.push_back(Type::VoidTy); > FunctionType *asm_type = FunctionType::get(Type::VoidTy, > asm_arguments, false); > > Alternatively > > FunctionType *asm_type = FunctionType::get(Type::VoidTy, >