[llvm-commits] [llvm] r46827 - memoperands #1
Dan Gohman
gohman at apple.com
Thu Feb 14 17:26:25 PST 2008
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
More information about the llvm-commits
mailing list