On Feb 12, 2008, at 1:42 PM, Chris Lattner wrote: > > 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?
There's a little redundancy; the MemOperand has flags to distinguish between load and store, and LSBaseNode has its opcode which is either LOAD or STORE. But that's not a big problem. > > >> 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? Yes, using a null Value* is done in many places right now that don't yet provide a proper SourceValue. Dan _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
