[PATCH] D83136: [NFC] Adding the align attribute on Atomic{CmpXchg|RMW}Inst

JF Bastien via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 6 14:48:48 PDT 2020


jfb added inline comments.


================
Comment at: llvm/include/llvm/IR/IRBuilder.h:1746
+    return Insert(new AtomicCmpXchgInst(
+        Ptr, Cmp, New, Alignment, SuccessOrdering, FailureOrdering, SSID));
   }
----------------
jyknight wrote:
> jfb wrote:
> > Are types always rounded to a power of two at this point?
> > 
> > i.e. what does this do: `struct { char c[3]; };` ?
> > 
> > Also, I think this is wrong for non-lock-free types. The alignment requirement is lower on those.
> This is just encoding the pre-existing behavior -- you cannot currently create an cmpxchg instruction with alignment other than the size of the type.
> 
> Right now, you _also_ cannot create a cmpxchg instruction with other than integral or pointer types, which -- in any _current_ llvm backend, afaik -- have non-power-of-2 sizes.
> 
> Upcoming changes will plumb through a required alignment argument everywhere, and then we'll be rid of this weird hardcoded special alignment behavior here.
That sounds good to me. FWIW I checked and we get the following today:
```
  %3 = bitcast %"struct.std::__1::atomic"* %0 to i32*
  %4 = zext i24 %1 to i32
  %5 = cmpxchg i32* %3, i32 %4, i32 %4 seq_cst seq_cst
  ret void
```
That being said, if we're going to allow other things to come into a cmpxchg in the future (i.e. remove the need to bitcast) then I want to make sure we encode the right requirements here, right now. I agree that they're enforced later in the code when the instruction is created, but that won't always be the case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83136/new/

https://reviews.llvm.org/D83136





More information about the llvm-commits mailing list