This is to match GCC's optimizations: https://gcc.godbolt.org/z/3odh9e7WE
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
30506 | Use enum { BIT_SET, BIT_CLEAR, BIT_RESET} to replace {0, 1, 2}? | |
30515 | Add comments that there is only 1 user checked in shouldExpandLogicAtomicRMWInIR()? | |
llvm/lib/Target/X86/X86InstrCompiler.td | ||
848 | Does LOG mean logic? Rename to ATOMIC_OP? | |
llvm/lib/Target/X86/X86IntrinsicsInfo.h | ||
40 ↗ | (On Diff #410121) | It seems LOCK_BITTEST is not used? |
llvm/include/llvm/IR/IntrinsicsX86.td | ||
---|---|---|
67 | Probably better as int_x86_atomic_bitttest? | |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
5450 | Does something check natural alignment before we create the intrinsic? | |
5451 | Does this need MOVolatile? | |
30520 | Does AI->getContext() work? | |
30526 | CreateBitCast -> createPointerCast | |
30526 | Probably doesn't really matter, but you should pass the address space to getInt8PtrTy. | |
30528 | ConstantInt::get(Type::getInt8Ty(Ctx), Imm) -> Builder.getInt8(Imm) | |
30529 | Builder.getInt32(SCR) | |
llvm/lib/Target/X86/X86InstrCompiler.td | ||
847 | Why no SDNPMayLoad? | |
848 | Can we use 3 separate intrinsics? I'm not sure this made up encoding is saving much. |
Address review comments. Thanks Craig!
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
5450 | Yes, it's checked by atomicSizeSupported in AtomicExpandPass.cpp | |
5451 | Maybe not. MOVolatile is usually set when isVolatile() return true in load and store instructions. We don't have such info in a target intrinsic. | |
30526 | I didn't see we pass address space when using CreatePointerCast, I guess the address space keep unchanged? |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
5451 | This information is used to create a MachineMemOperand. I think that MachineMemOperand needs to know this access can't undergo certain optimizations because it represents an atomic access. I don't think this interface can create an atomic MachineMemOperand, but it can create a volatile one. |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
5451 | volatile is an memory attribute which is not atomic exclusive. https://godbolt.org/z/1o9Y7j5xe |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
5451 | Do the LOCK_BTS/BTR/BTC show up in MIR with "monotonic"(or other atomic ordering) in their memory operand printing in MIR? If not you have a bug waiting to happen. I think "volatile" is stronger than any of the atomic orderings. So it works in place of them. RISCV uses MOVolatile in getTgtMemIntrinsic for riscv_masked_atomicrmw* |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
5451 | The important thing is that the isUnordered() method on the MachineMemOperand must return false if the original atomicrmw was ordered. |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
5451 | I see. Yeah, I have worry on the same thing. That's why I didn't use target intrinsic at beginning. I'm glad it solves my problems. Thanks Craig! |
Probably better as int_x86_atomic_bitttest?