[llvm-commits] [llvm] r46827 - memoperands #1

[Chris Lattner]

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