> 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 :) 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.
On Sat, Jun 12, 2010 at 6:23 AM, Duncan Sands <baldrick at free.fr>
wrote:>> 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 :)
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
On Jun 12, 2010, at 5:37 AM, Kenneth Uildriks wrote:> 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
On 12 June 2010 04:23, Duncan Sands <baldrick at free.fr> wrote:> > 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 :) >It might even mean that they use {}* for void*, instead of overloading the meaning of i8*, which would be nice.