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 StructTy* VoidTy instead of Type VoidTy
VoidTy may be Identified struct. In addition to error occurs at
test/Analysis/BasicAA/empty.ll
because of using literal struct "{}" as VoidTy
4. Re-implement isVoidTy().
Test whether the address of the type equals Type::getVoidTy()
=== Request For Command ==
The constructor form of ReturnInst
Any suggestion is welcomed.
Thanks a lot
Mitnick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120507/cf55129d/attachment.html>
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 should not be obliged to use that. For example they could use [] or {{}} etc.> === Further Implementation Details ==> > 1. Deleting VoidTyIDYes!> 2. Deleting LLVMVoidTypeKind (one-to-one relation between VoidTyID and > LLVMVoidTypeKind)Yes!> 3. Use StructTy* VoidTy instead of Type VoidTyNo! This doesn't make any sense to me. Why would having a definition for VoidTy be needed or desirable?> VoidTy may be Identified struct. In addition to error occurs at > test/Analysis/BasicAA/empty.ll > because of using literal struct "{}" as VoidTy > > 4. Re-implement isVoidTy().No! Just delete void type, don't try to create a canonical replacement for it. Ciao, Duncan.> Test whether the address of the type equals Type::getVoidTy() > > === Request For Command ==> > The constructor form of ReturnInst > > Any suggestion is welcomed. > > Thanks a lot > > Mitnick > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 > something instead of void, and {} is an example of what they might produce, but > they should not be obliged to use that. For example they could use [] or {{}} > etc. > >> === Further Implementation Details ==>> >> 1. Deleting VoidTyID > Yes! > >> 2. Deleting LLVMVoidTypeKind (one-to-one relation between VoidTyID and >> LLVMVoidTypeKind) > Yes! > >> 3. Use StructTy* VoidTy instead of Type VoidTy > No! This doesn't make any sense to me. Why would having a definition for > VoidTy be needed or desirable? > >> VoidTy may be Identified struct. In addition to error occurs at >> test/Analysis/BasicAA/empty.ll >> because of using literal struct "{}" as VoidTy >> >> 4. Re-implement isVoidTy(). > No! Just delete void type, don't try to create a canonical replacement for it.The value of still having something like a VoidTy in the API is that it would reduce the amount of code that needs to change. Much of our code at Illinois uses void type; I imagine lots of other LLVM code (including code in LLVM) does as well. Going further, it's not clear to me why people want to get rid of the void type. Is there a lot of special casing that would go away if VoidTy were removed? All of the justification in Chris's note appears, for lack of a better word, cosmetic. It's a cleaner design, but the cost of "fixing" the issue seems to outweigh its benefit. -- John T.> > Ciao, Duncan. > >> Test whether the address of the type equals Type::getVoidTy() >> >> === Request For Command ==>> >> The constructor form of ReturnInst >> >> Any suggestion is welcomed. >> >> Thanks a lot >> >> Mitnick >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 too literally, or when they try to create pointers to void. But these problems are quickly caught and easily corrected. 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. 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. Dan
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.