Hi Dan,>> 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? Ciao, Duncan.
On May 9, 2012, at 12:28 AM, Duncan Sands wrote:> Hi Dan, > >>> 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. Dan
>>>> 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.