If we have SSE2 we can use a MOVQ to store 64-bits and avoid falling back to a cmpxchg8b loop. If its a seq_cst store we need to insert an mfence after the store.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 30357 Build 30356: arc lint + arc unit
Event Timeline
llvm/test/CodeGen/X86/atomic-fp.ll | ||
---|---|---|
152–153 | There is an extra stack temporary here due to type legalization of the bitcast from f64 to i64 being legalized as a stack store f64 and then two i32 loads. DAG combine was able to merge the loads probably using merge elts from consecutive loads to create a VZEXT_LOAD. | |
llvm/test/CodeGen/X86/atomic6432.ll | ||
841 | Not sure why we didn't merge consecutive loads here. |
llvm/lib/Target/X86/X86ISelLowering.h | ||
---|---|---|
594 | If we used MOVSD (f64 store) could we avoid needing this NodeType? |
llvm/lib/Target/X86/X86ISelLowering.h | ||
---|---|---|
594 | if we don't use a dedicated X86ISD opcode, then we have to use ISD::ATOMIC_STORE. TargetSelectinoDAG has this type constraint which says that the store value type is integer. Perhaps we can relax that, but I don't know if there is some code assuming this. def SDTAtomicStore : SDTypeProfile<0, 2, [ SDTCisPtrTy<0>, SDTCisInt<1> ]>; def atomic_store : SDNode<"ISD::ATOMIC_STORE", SDTAtomicStore, [SDNPHasChain, SDNPMayStore, SDNPMemOperand]>; |
LGTM
llvm/lib/Target/X86/X86ISelLowering.h | ||
---|---|---|
594 | OK - please can you raise a bug about whether SDTCisInt<1> can be relaxed? |
If we used MOVSD (f64 store) could we avoid needing this NodeType?