similar to: [LLVMdev] Discussion of eliminating the void type

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

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 >

Hello Chris, The general concept is to replace void with {}. Void is a weird type in > that it is only allowed as the return value of functions and as the type of > instructions like store. It seems better (though also not particularly > high priority) to eliminate it to make the type system more consistent. > > -Chris > I also noticed a sentence "We can even make

Hi Dan, >> I am willing to do "eliminating the void type" project. > > Is this really a good idea? I'm not going to argue at length > about it, but it is worth thinking about. > > The only practical downsides of void are when newcomers take C's > syntax for functions with no arguments a little too literally, or > when they try to create pointers to

Hello Duncan, There is a discussion with Chris Lattner: http://old.nabble.com/Eliminating-the-'void'-type-td33726468.html In the discussion, Chris Lattner suggest Type::getVoidTy() should still exist and return {} for API continuity. If VoidTy and isVoidTy() go away, how do deal with the isVoidTy() function call in LLVM source tree? Another issue is: What should ReturnInst constructor

Hello all, I noticed Eliminating the 'void' type<http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt>in Random LLVM notes. I am wondering to know what's the meaning of "eliminating" the void type. Is it means the goal is deleting VoidTyID from TypeID enumeration in Type.h? And what Type::getVoidTy() returned is a pointer to a {}? Thanks Mitnick -------------- next

On Apr 22, 2012, at 3:44 AM, Lyu Mitnick wrote: > Hello Chris, > > The general concept is to replace void with {}. Void is a weird type in that it is only allowed as the return value of functions and as the type of instructions like store. It seems better (though also not particularly high priority) to eliminate it to make the type system more consistent. > > -Chris > >

Hello Chris The general concept is to replace void with {}. Void is a weird type in >> that it is only allowed as the return value of functions and as the type of >> instructions like store. It seems better (though also not particularly >> high priority) to eliminate it to make the type system more consistent. >> > MVT::isVoid and Type::VoidTyID (getVoidTy) have

On May 7, 2012, at 8:07 AM, Lyu Mitnick <mitnick.lyu at gmail.com> wrote: > Hello all, > > I am willing to do "eliminating the void type" project. Is this really a good idea? I'm not going to argue at length about it, but it is worth thinking about. The only practical downsides of void are when newcomers take C's syntax for functions with no arguments a little

On Apr 21, 2012, at 12:17 PM, Lyu Mitnick wrote: > Hello all, > > I noticed Eliminating the 'void' type in Random LLVM notes. I am wondering to know what's the > meaning of "eliminating" the void type. Is it means the goal is deleting VoidTyID from TypeID > enumeration in Type.h? And what Type::getVoidTy() returned is a pointer to a {}? The general concept

On Apr 23, 2012, at 5:57 AM, Lyu Mitnick wrote: > Hello Chris > >> The general concept is to replace void with {}. Void is a weird type in that it is only allowed as the return value of functions and as the type of instructions like store. It seems better (though also not particularly high priority) to eliminate it to make the type system more consistent. > > MVT::isVoid

>>>> there's a difference between users of LLVM (which you discuss here) >>>> and developers of LLVM (people writing transforms etc). I agree >>>> that for users it just changes one oddity for another. However for >>>> developers it should make things simpler by making the IR more uniform. >>> >>> As a developer, it would be

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?

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

Hi, both versions are working: FunctionType *asm_Ftype = FunctionType::get(Type::VoidTy, std::vector<const Type*>(), false); InlineAsm* Iasm = InlineAsm::get(asm_Ftype,"isync","~{dirflag},~{fpsr},~{flags}",true); How can I insert this InlineAsm, because it is no instruction and this way it will not work: Instruction *pi = bi;

Hi, I got a problem when I am trying to insert a call function with pointer arguments. The function C proto-type is the following, void stat_func(char *); >ConstantArray *Cstr = dyn_cast<ConstantArray>(gI->getInitializer()); ...... >Function *exFunc = M->getOrInsertFunction("stat_func", Type::VoidTy, PointerType::get(Type::SByteTy),0); >std::vector<Value*>

I recently began hacking around with my first LLVM pass. The big picture is that I would like to insert function calls for each instruction type, and pass some parameters based on the instruction type. Then I will link the output to some C file that implements those functions. Things were going well until I started trying to make function calls with a pointer as a parameter. For example, I would

Hi Gordon, > > I'm authoring a C interface to the LLVM IR type system. It's great to see a C interface being added. A minor niggle: > +typedef enum { > + LLVMVoidTypeKind = 0, /* type with no size */ > ... > +typedef enum { > + LLVMExternalLinkage = 0,/* Externally visible function */ > ... > +typedef enum { > + LLVMDefaultVisibility = 0, /* The GV

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

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;