[LLVMdev] Discussion of eliminating the void type

[Duncan Sands]

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.