search for: eliminatingvoid

Hi all, For anyone interested, I posted two new ideas for changes to the LLVM IR. The first is basically a cleanup, the second is a major new feature: Eliminating the 'Void' Type: http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt Aggregates as First Class Values: http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt Thanks to Dan Gohman for convincing me that aggregates as first class values is really possible, I think it is a great idea. -Chris

Hi Chris, > Eliminating the 'Void' Type: > http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt might not some ABI's require some special stuff when returning a struct, regardless of whether the struct is empty or not? If so this might add a cost if you use {} for void. Also, there are an infinite number of different ways of returning void: return {} or {{}} or {{{}}} etc, not to m...

...This also requires a > guarantee that > nothing special happens to the return value as a whole, but only the > individual elements are accessed through extractvalue. After MRVs are working really well, I'd like to consider removing the void type: http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt This would make it so that calls always return a value, and 'ret' always takes a value. This would be a nice simplification to the IR I think. > > > >> Ok. And as I mentioned before, we can add buildagg (maybe with a >> different name ;-)) > Yeah, builddag...

Hello all, I noticed Eliminating the 'void' type<http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt>in Random LLVM notes. I am wondering to know what's the meaning of "eliminating" the void type. Is it means the goal is deleting VoidTyID from TypeID enumeration in Type.h? And what Type::getVoidTy() returned is a pointer to a {}? Thanks Mitnick -------------- next part -----...

...ing value. Chris Lattner wrote: > Hi all, > > For anyone interested, I posted two new ideas for changes to the LLVM > IR. The first is basically a cleanup, the second is a major new > feature: > > Eliminating the 'Void' Type: > http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt > > Aggregates as First Class Values: > http://nondot.org/sabre/LLVMNotes/FirstClassAggregates.txt > > Thanks to Dan Gohman for convincing me that aggregates as first class > values is really possible, I think it is a great idea. > > -Chris > _______________________...

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

...gether with whatever you want to add and then letting other passes make something pretty out of the resulting extractvalue/insertvalue forest will work just fine. > After MRVs are working really well, I'd like to consider removing the > void type: > http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt > > This would make it so that calls always return a value, and 'ret' > always takes a value. This would be a nice simplification to the IR I > think. Doing this will make functions returning a single value stand out even more, since a function returning 0 or more than...