Void values

Hi,

I'm interested in adding support for void values (i.e. unit types) to LLVM. Currently, "void" is only allowed as the return value of a function, and numerous assertions are in place to check this.

This document [1] that Google pulled up seems to suggest that this idea was planned:

> Finally, one annoying, but trivial, nuance of the LLVM type-system is
> the 'void' type, which is only currently allowed as the return value
> of a function. Special cases like this should be eliminated.

Is this still the case, and if so, is there any work being done on this already?

Thanks!
Patrick

[1] http://www.nondot.org/~sabre/LLVMNotes/MultipleReturnValues.txt

Hi Patrick,

I don't know of anyone working on it, but I'd really like to eliminate void. It doesn't seem like a useful feature of the type system. Functions can be changed to return {} for example.

-Chris

That's the structure type with zero elements, right?

Patrick

Yep, exactly.

-Chris

I don't know of anyone working on it, but I'd really like to eliminate void. It doesn't seem like a useful feature of the type system. Functions can be changed to return {} for example.

Not having a void type also means that people writing front-ends for C-like
languages won't try to convert "void*" into a pointer to the LLVM void type
and be confused when it doesn't work :slight_smile:

Ciao,

Duncan.

Are there any platforms where it wouldn't Just Work if the code
generator generated a {} return everywhere it presently generates a
void return? I'm not saying make those changes to the code generator,
I'm just asking if VMCore replaced void with {} would any code
generators need changing? I don't think X86 would be affected - EAX
is not preserved even if the function returns void.

I don't think so, but noone has done the experiment to see the fallout. The biggest issue is that in code like this:

  %1 = add i32 ...
  store ...
  %2 = mul i32 %1, ...

That the numbering gets broken because store now produces a (unit) value. For this issue alone, it may be an "llvm 3.0" sort of change.

-Chris

It might even mean that they use {}* for void*, instead of overloading
the meaning of i8*, which would be nice.