similar to: [LLVMdev] Eliminating the 'void' type

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

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

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

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

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

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

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

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

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

Hi LLVM, In lib/VMCare/Verifier.cpp::visitInstruction, we have such code 1287 // Check that the return value of the instruction is either void or a legal 1288 // value type. 1289 Assert1(I.getType() == Type::getVoidTy(I.getContext()) || 1290 I.getType()->isFirstClassType() 1291 || ((isa<CallInst>(I) || isa<InvokeInst>(I)) 1292 &&

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

I am trying to compile a little intrinsic function for my machine. Here is a dump from clang-cc with --emit-llvm option: ===================== ; ModuleID = 'foo.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i386-pc-linux-gnu" @main.i = internal global i32

Hello LLVMDev, I'm George, an intern for Google who will be working on LLVM. Currently, I'm starting to implement a set-based Alias Analysis algorithm for LLVM, which looks like it may be more accurate than Steensgard's, and can be constructed in approximately nlog(n) time and linear space (n = number of memory locations; queries happen in constant time). It will most likely be

Hello all, I have read the chapter "Writing an LLVM Pass" and noticed that there is a topic "Multithreaded LLVM". However I have no idea about this. I am wondering to know whether the goal of this extension is: 1. Multiple threads handle different modules (Thread : Module = 1 : 1) or 2. Multiple threads handle one module (Thread : Module = N : 1) Thanks a lot --------------

On Jan 6, 2010, at 1:12 PM, fima rabin wrote: > I am trying to compile a little intrinsic function for my machine. Here is a dump from clang-cc with --emit-llvm option: > ===================== > > ; ModuleID = 'foo.c' > target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" >

Hello, Is there any exist LLVM Target (backend) that support PC relative load and store? If so, what exactly is the instruction? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191204/c345ac5c/attachment.html>

Hi, I want to insert a function with a void type parameter, for example: int foo(void); OI declared fcall2 = M.getOrInsertFunction("foo", IntegerType::get(M.getContext(), 32), Type::getVoidTy(M.getContext())); then the question is how to get the void type value to make the CallInst inserted sucessfully? (what should be ********) CallInst::Create(fcall2, ******,

Hello Jakob, Is this means that TableGen execution is handled in Makefile. Porting programmer doesn't need to execute TableGen by hand? thanks 2011/3/10 Jakob Stoklund Olesen <stoklund at 2pi.dk> > > On Mar 9, 2011, at 2:13 PM, Lu Mitnick wrote: > > > Hello all, > > > > I have some question about usage of TableGen when adding a new LLVM > Backend. There