search for: memintrinsicsdnode

...6 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specific memory model hint + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode here is the current SDNode class hierarchy of memory related nodes SDNode -> MemSDNode -> LS...

...6 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specific memory model hint + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode here is the current SDNode class hierarchy of memory related nodes SDNode -> MemSDNode -> LS...

...model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes > > SDNode -&...

...bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes >...

...bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes >...

...bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rationale how such target flags are embedded into > SubclassData in SDNode > > here is the current SDNode class hierarchy of memory related nodes >...

...general memory model.) To follow the similar approach, I propose to >> change LLVM/clang by adding: >> >> + a metadata 'targetflags' in LLVM atomic IR to pass this >> target-specific memory model hint >> >> + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints >> This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are embedded into SubclassData in SDNode >> >> here is the current SDNode class hierarchy of memory related nodes >> &...

Hello, I've hit an assertion in SelectionDAG where we try to merge 2 loads that have the same operands but their MMO flags differ. One is dereferenceable and one is not. I'm not sure what the underlying issue here is: 1) MDSDNode with the same operands should have the same flags set on their respective MMO. The fact the flags differ when the opcode,types,operands and address-space are