On Feb 12, 2008, at 11:27 AM, Dan Gohman wrote: > Hi Chris, > > Thanks for the careful review! I've responded to parts of it already, > and I'll > be responding to more soon.
Thanks Dan! > On Feb 10, 2008, at 11:56 AM, Chris Lattner wrote: >> Instead of Size here, would it make sense to store an MVT? That >> would >> seem to capture strictly more information, thought I'm not sure if >> it's directly useful right now. > > This, and the question of whether to make LSBaseNode store a > MemOperand > instead of separate fields, are related. Ok, right. What is your opinion on this? Is there any reason not to give MemOperand a VT and then give LSBaseNode a MemOperand? > Also related is the question is what to do about the lowering of > something like > insert vector element where the element index isn't a constant and the > target > doesn't have an instruction to handle it. Legalize emits a store with > a computed > offset; what should the MemOperand for this look like? One way is to > give it a > larger size, to cover the known area over which the store might occur. > This > would mean it would use a different VT from the actual store, which > could be > confusing. Maybe it should have both a size and a VT. Good question. This sort of thing is currently rare enough that it is probably fine to just use a null Value*, and have everything treat it conservatively. Would this be acceptable for now? -Chris _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits