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
Details
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/test/CodeGen/X86/atomic-fp.ll | ||
---|---|---|
152 ↗ | (On Diff #194602) | 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 ↗ | (On Diff #194602) | Not sure why we didn't merge consecutive loads here. |
llvm/lib/Target/X86/X86ISelLowering.h | ||
---|---|---|
594 ↗ | (On Diff #194637) | If we used MOVSD (f64 store) could we avoid needing this NodeType? |
llvm/lib/Target/X86/X86ISelLowering.h | ||
---|---|---|
594 ↗ | (On Diff #194637) | 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]>; |
Comment Actions
LGTM
llvm/lib/Target/X86/X86ISelLowering.h | ||
---|---|---|
594 ↗ | (On Diff #194637) | OK - please can you raise a bug about whether SDTCisInt<1> can be relaxed? |