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

[Dan Gohman]

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