Since 2.7 is getting close to code freeze, I'd like to see if I can get in our
changes to track non-temporal memory operations into trunk.
As discussed earlier, I was hoping to do this via metadata. It's pretty clear
how to attach the data to Instructions, but after that, I'm not sure what
happens. Somehow we have to carry this all the way back into MachineInstrs.
What happens to metadata when SelectionDAGs get built? Is it lost?
Is there any mechanism to attach metadata to SDNodes or MachineInstrs?
-Dave
Since 2.7 is getting close to code freeze, I'd like to see if I can get in our
changes to track non-temporal memory operations into trunk.
As discussed earlier, I was hoping to do this via metadata. It's pretty clear
how to attach the data to Instructions, but after that, I'm not sure what
happens. Somehow we have to carry this all the way back into MachineInstrs.
What happens to metadata when SelectionDAGs get built? Is it lost?
It is still there.
Is there any mechanism to attach metadata to SDNodes or MachineInstrs?
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.
-Chris
How do I get to it after all the SelectionDAG stuff is run? I need to be able
to write TableGen patterns that look for the metadata and generate a
different MachineInstr.
-Dave
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.
-Dave
I think that adding a bit to LoadSDNode and StoreSDNode would make sense.
-Chris
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
Putting a bit (or multiple bits) in MachineMemOperand for this
would also make sense.
Dan
Is there any chance a MachineMemOperand will be shared by multiple
instructions?
-Dave
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
Then we can't use it to hold a non-temporal flag. The operand might be
non-temporal in one context but it may not be in another.
-Dave
Sharing only happens when two instructions have the "same" memory
reference info. You just need to make sure that the non-temporal
flag is significant. It's not fundamentally different from the
volatile flag in this respect.
Dan
Well, that's a rat's nest. I backed up and thought maybe I have the metadata
syntax wrong.
So I tried a bunch of things:
%r8 = load <2 x double>* %r6, align 16, metadata !"nontemporal"
%r8 = load <2 x double>* %r6, align 16, metadata !nontemporal
%r8 = load <2 x double>* %r6, align 16, !{ metadata !"nontemporal" }
%r8 = load <2 x double>* %r6, align 16, !{ metadata !nontemporal }
%r8 = load <2 x double>* %r6, align 16, !{ !"nontemporal" }
%r8 = load <2 x double>* %r6, align 16, !{ !nontemporal }
I give up! What is the syntax for attaching metadata to instructions? The
documentation is very unclear.
-Dave
Some examples are in llvm/test/Feature/md_on_instruction.ll
Or you could just compile a file with -g.
-Chris
Try
%r8 = load <2 x double>* %r6, align 16, !nontemporal !1
!1 = metadata !{ i32 1, metadata !0, null, metadata !"foobar" }
And then fix the documentation!
What does that mean? "foobar?" Seems awfully wordy to convey a single
bit of information.
-Dave
But neither of these explains what the grammar is. It looks like gibberish to
me...
-Dave
I don't think the lang ref metadata grammar section (http://llvm.org/docs/LangRef.html#metadata) has been fully updated
with how !dbg metadata is used in http://llvm.org/docs/SourceLevelDebugging.html. At least to me it is not clear. In my
mind I translate the phrase "LLVM IR allows metadata to be attached to instructions " into a grammar depicted in
SourceLevelDebugging.html. I was going to ask about this, but I'll let you instead.
Garrison