llvm dev - Feb 2010 - [LLVMdev] Metadata

On Feb 10, 2010, at 10:20 AM, David Greene wrote:
> On Wednesday 10 February 2010 11:46:25 Chris Lattner wrote:
> 
>>> There is not any mechanism to attach metadata with SDNode or
>>> MachineInstrs today.
>> 
>> For nontemporal stores, you wouldn't want to do this anyway.  In
>> selectiondag builder, you'd want to check the store instruction to
see if
>> it has the metadata on it, and if so make a different ISD opcode or
>> something.
> 
> Ah, ok, I could do that.  The way we did this here was to add some
information
> into the SDNode and then write a TableGen predicate to check it, generating
> a different kind of store instruction.  This avoided the need for a new
target
> ISD opcode.
> 
> In general, is one method preferred over the other?  That is, if target-
> specific ISD opcodes can be avoided, should we avoid them?
> 
> Is there any reason we would not want to support metadata on SDNodes,
> other than the cost of implementing it?  We don't necessarily need to
do that
> now.  I'm just asking the question with future possibilities in mind.
I think that adding a bit to LoadSDNode and StoreSDNode would make sense.

-Chris

On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote:
> I think that adding a bit to LoadSDNode and StoreSDNode would make sense.
Ok.  The consequence is that a number of functions will have to change to
propagate this bit, analogous to what happens with isVolatile.  It's 
essentially what we do right now here.  If everyone's ok with that, I'll
go
that route.

                                                 -Dave

On Feb 10, 2010, at 12:42 PM, David Greene wrote:
> On Wednesday 10 February 2010 12:58:25 Chris Lattner wrote:
> 
>> I think that adding a bit to LoadSDNode and StoreSDNode would make
sense.
> 
> Ok.  The consequence is that a number of functions will have to change to
> propagate this bit, analogous to what happens with isVolatile.  It's 
> essentially what we do right now here.  If everyone's ok with that,
I'll go
> that route.
Putting a bit (or multiple bits) in MachineMemOperand for this
would also make sense.

Dan