================
@@ -4105,14 +4102,21 @@ LValue ScalarExprEmitter::EmitCompoundAssignLValue(
// the loaded integer to double, performing FP arithmetics, and truncation
// back as a single atomic operation. Integer promotion is still
// semantically safe.
- bool CanEmitAtomicRMW =
+ bool CanEmitIntegerRMW =
!AtomicValueTy->isBooleanType() && AtomicValueTy->isIntegerType() &&
ResultTy->isIntegerType() &&
!(AtomicValueTy->isUnsignedIntegerType() &&
CGF.SanOpts.has(SanitizerKind::UnsignedIntegerOverflow)) &&
CGF.getLangOpts().getSignedOverflowBehavior() !=
LangOptions::SOB_Trapping;
- if (CanEmitAtomicRMW) {
+ bool CanEmitFloatingRMW = false;
+ if (!Builder.getIsFPConstrained() && AtomicValueTy->isFloatingType() &&
+ CGF.getContext().hasSameUnqualifiedType(AtomicValueTy, ResultTy)) {
+ llvm::Type *IRTy = CGF.ConvertType(AtomicValueTy);
+ uint64_t StoreBits =
CGF.CGM.getDataLayout().getTypeStoreSizeInBits(IRTy);
+ CanEmitFloatingRMW = llvm::isPowerOf2_64(StoreBits);
+ }
+ if (CanEmitIntegerRMW || CanEmitFloatingRMW) {
----------------
paulwalker-arm wrote:
The `CanEmitIntegerRMW/CanEmitFloatingRMW` split looks awkward. Do we really
want to allow the same operations for integer and floating-point types?
Perhaps keep and update `CanEmitAtomicRMW` and then have two blocks chosen
based on `AtomicValueTy->isFloatingType()` where only the relevant opcodes are
handled?
https://github.com/llvm/llvm-project/pull/216033
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
