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 void. But these problems are > quickly caught and easily corrected.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.> Replacing void with {} will actually make the language more > deceptive, because if newcomers think {} is LLVM's spelling for > C's void, they might be tempted to use {}* for C's void*, and > nothing will stop them except mysterious bugs if they do > arithmetic.I think this is a dubious argument. Being able to do pointer arithmetic on void * was only an odd GCC extension as far as I know, not a general C feature. Anyone who makes this mistake will pretty much instantly discover that there is a problem. Anyway, conceptually the idea is not to replace void with {}, it's to remove void because there are alternatives such as {}, {{}} etc.> On the purity side, replacing void with {} has the side effect of > emphasising an odd asymmetry in the language. Conisder the return > types of functions returning 0, 1, 2, and 3 etc. values: > > 0: {} > 1: i32 > 2: {i32,i32} > 3: {i32,i32,i32} > etc. > > Why is 1 special-cased? Argument lists don't have a corresponding > special case, after all.You could return one value as {i32}. But you are right, there is an asymmetry. It already existed, I don't see how eliminating void makes things worse, it only makes things more regular by no longer distinguishing between the 0 case and the 2, 3, ... case. Ciao, Duncan.
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 looks like with VoidTy or not?
Thanks
Mitnick
Hi Mitnick,> 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.don't listen to that Chris guy! :) I think that that's a mistake, and it would be better to eliminate the void concept entirely from the LLVM core. Instead I reckon that IRBuilder (which already has some convenience methods for getting hold of types) should gain methods getVoidTy, returning {}, and getVoidPtrTy, returning i8* (with a comment explaining why it is not returning {}*). Summary: the core should be kept conceptually clean and uniform, convenience wrappers should go in IRBuilder. If VoidTy and isVoidTy() go away, how do deal with> the isVoidTy() function call in LLVM source tree?Replace it with false everywhere, which in general will just mean deleting that bit of code. After all, the existing code already has to handle {} correctly, since people can already write this, and that returns false for isVoidTy. [I could change dragonegg today to output {} whereever it uses void right now, and it should work, though bugs are always possible]. I suggest you go about things like this: first convert the clang front-end to use {} everywhere instead of void (maybe enhancing IRBuilder by adding helpful methods). I'm happy to do the same for dragonegg. This may require fixing some bugs in LLVM, i.e. code that doesn't handle {} properly (code that was already broken but no-one noticed). Once front-ends simply aren't producing void type any more, you can delete VoidTy and replace every use of isVoidTy with false (which is correct since it can never return true since there will be no void type in any IR any more). Another issue is: What should> ReturnInst constructor looks like with VoidTy or not?I didn't understand the question. Are you asking whether there should be some convenience constructors which result in returning {}, while previously they would return void? In my opinion there should be no such constructors. Any such convenience methods should be in IRBuilder. That already has CreateRetVoid which can now create a "return {} {}" instead. Ciao, Duncan.
On May 8, 2012, at 12:36 AM, Duncan Sands <baldrick at free.fr> wrote:> 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 void. But these problems are >> quickly caught and easily corrected. > > 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 mildly nice to give stores names. However, that may be more than offset by the fact that store instructions would be able to have users. It'd always be safe to RAUW a store with undef {}, but that's a nuisance. Dan
Hi Dan,>> 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 mildly nice to give stores names. > However, that may be more than offset by the fact that store instructions > would be able to have users. It'd always be safe to RAUW a store with > undef {}, but that's a nuisance.at this point I should confess that I was only thinking of function return types when talking about void type, and forgot that StoreInst returns a type, void type. How about having getType return null for StoreInst and similar? Ciao, Duncan.