>>>> 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? > > That sounds like it would be an awkward special case.Yes, in fact this issue has put me off the whole idea of getting rid of void type. Ciao, Duncan.
Hello Duncan, Dan According to the thread, I am wondering to know whether the current design is relatively better than getting rid of void type, which means the idea "eliminating the void type" may be removed from LLVM random notes? Thanks a lot Mitnick>>>>> 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? >> >> That sounds like it would be an awkward special case. > > Yes, in fact this issue has put me off the whole idea of getting rid of void > type. > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
I have to confess that I find the whole idea crazy. It seems a lot of pain for everyone for very little gain. Evan On May 9, 2012, at 8:33 AM, Duncan Sands wrote:>>>>> 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? >> >> That sounds like it would be an awkward special case. > > Yes, in fact this issue has put me off the whole idea of getting rid of void > type. > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Evan Cheng wrote:> I have to confess that I find the whole idea crazy. It seems a lot of pain for everyone for very little gain.IIRC, part of the point of removing void was so that we could have users of store/br/unreachable/etc. and allow the instructions to have names. The users would be restricted to being metadata. Nick> Evan > > On May 9, 2012, at 8:33 AM, Duncan Sands wrote: > >>>>>> 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? >>> >>> That sounds like it would be an awkward special case. >> >> Yes, in fact this issue has put me off the whole idea of getting rid of void >> type. >> >> Ciao, Duncan. >> _______________________________________________ >> 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 >