search for: buildagg

...ime trying to find out what these nested insertvalues actually do. The main difference here is that using insertvalue you can do something like: %a = phi { i32, i32 } [ %a.0, %foo ], [ %a.1, %bar ] %b = insertvalue { i32, i32 } %a, i32 0, 0 which you can't do directly using a literal { } or buildagg kind of instruction. OTOH, you can still do things like this using nested structs then, so having a builddag will probably not improve things much. Anyhow, so much for my blabbering of incoherent thoughts. I think that simply using insertvalue for now and not having an explicit multiple return fun...

...ested insertvalues actually do. > The main > difference here is that using insertvalue you can do something like: > > %a = phi { i32, i32 } [ %a.0, %foo ], [ %a.1, %bar ] > %b = insertvalue { i32, i32 } %a, i32 0, 0 > > which you can't do directly using a literal { } or buildagg kind of > instruction. OTOH, you can still do things like this using nested > structs > then, so having a builddag will probably not improve things much. > > Anyhow, so much for my blabbering of incoherent thoughts. I think > that simply > using insertvalue for now and not...

...32 %b } would be a lot more useful than the current ret i32 %a, i32 %b form, since in the first form the ret instruction still has a single operand that is easy to work with. Perhaps if using a non-constant literal struct is not so trivial, a instruction can be added for that instead. Ie, %res = buildagg i32 %a, i32 %b ret %res This is still a clean way of building a struct (a lot easier to work with than nested insertvalues IMHO) but also leaves the ret instruction simple. Anyway, if using a literal struct as an operand would work, then the multiple return value ret instruction can probably be...

...ucts take over from the current multiple-return- value support. It's significantly more syntax, but it's a significantly simpler IR schema. > > > Perhaps if using a non-constant literal struct is not so trivial, a > instruction can be added for that instead. Ie, > %res = buildagg i32 %a, i32 %b > ret %res > > This is still a clean way of building a struct (a lot easier to work > with than > nested insertvalues IMHO) but also leaves the ret instruction simple. This looks nice, and I wouldn't rule out doing it in the future, but it gets a little awkward...

...alues is really not used anywhere except for sretpromotion (and there not really either), this is probably not a big deal. However, for our particular applications we like the function results to be as flat as possible, to simplify our codegeneration. > Ok. And as I mentioned before, we can add buildagg (maybe with a > different name ;-)) Yeah, builddag is an ugly name :-p > later if we find it would be of significant use or convenience. By then, we will probably have though our backend to read insertvalue chains, so it won't be really necessary anymore :-) But let's keep it in min...

...ving 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 is an ugly name :-p > >> later if we find it would be of significant use or convenience. > By then, we will probably have though our backend to read > insertvalue chains, > so it won't be really necessary anymore...