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
On Wednesday 10 February 2010 14:58:58 Dan Gohman wrote:> 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.Is there any chance a MachineMemOperand will be shared by multiple instructions? -Dave
On Feb 11, 2010, at 11:31 AM, David Greene wrote:> On Wednesday 10 February 2010 14:58:58 Dan Gohman wrote: >> 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. > > Is there any chance a MachineMemOperand will be shared by multiple > instructions?Yes. Dan
On Thursday 11 February 2010 13:31:58 David Greene wrote:> > Putting a bit (or multiple bits) in MachineMemOperand for this > > would also make sense. > > Is there any chance a MachineMemOperand will be shared by multiple > instructions?So I tried to do this: %r8 = load <2 x double>* %r6, align 16, !"nontemporal" and the assembler doesn't like it. Do I need to use named metadata? That would be rather inconvenient. The problem is this code in llvm-as: int LLParser::ParseLoad(Instruction *&Inst, PerFunctionState &PFS, bool isVolatile) { Value *Val; LocTy Loc; unsigned Alignment = 0; bool AteExtraComma = false; if (ParseTypeAndValue(Val, Loc, PFS) || ParseOptionalCommaAlign(Alignment, AteExtraComma)) return true; [...] } /// ParseOptionalCommaAlign /// ::= /// ::= ',' align 4 /// /// This returns with AteExtraComma set to true if it ate an excess comma at the /// end. bool LLParser::ParseOptionalCommaAlign(unsigned &Alignment, bool &AteExtraComma) { AteExtraComma = false; while (EatIfPresent(lltok::comma)) { // Metadata at the end is an early exit. if (Lex.getKind() == lltok::MetadataVar) { AteExtraComma = true; return false; } if (Lex.getKind() == lltok::kw_align) { if (ParseOptionalAlignment(Alignment)) return true; } else return true; } return false; } Either ParseLoad and probably other instructions need to look for metadata explicitly or ParseOptionalCommaAlign needs to know about general metadata. My inkling is to fix ParseOptionalCommaAlign. Sound reasonable? -Dave