[clang][CodeGen] Add range metadata for atomic load of boolean type. #131476 #133546

janagor · 2025-03-29T00:39:47Z

Addresses #131476.

For x86_64 it folds

movzbl	t1(%rip), %eax
andb	$1, %al

into

movzbl	t1(%rip), %eax

when run: clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=x86_64.

But for riscv replaces:

lb	a0, %lo(t1)(a0)
andi	a0, a0, 1

with

lb	a0, %lo(t1)(a0)
zext.b	a0, a0

when run: clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=riscv64.

github-actions · 2025-03-29T00:40:10Z

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

llvmbot · 2025-03-29T00:40:41Z

@llvm/pr-subscribers-backend-powerpc
@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-codegen

Author: Jan Górski (janagor)

Changes

Addresses #131476.

For x86_64 it folds

movzbl	t1(%rip), %eax
andb	$1, %al

into

movzbl	t1(%rip), %eax

when run: clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=x86_64.

But for riscv replaces:

lb	a0, %lo(t1)(a0)
andi	a0, a0, 1

with

lb	a0, %lo(t1)(a0)
zext.b	a0, a0

when run: when run clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=riscv64`.

Full diff: https://github.com/llvm/llvm-project/pull/133546.diff

2 Files Affected:

(modified) clang/lib/CodeGen/CGAtomic.cpp (+23)
(added) clang/test/CodeGen/atomic-ops-load.c (+11)

diff --git a/clang/lib/CodeGen/CGAtomic.cpp b/clang/lib/CodeGen/CGAtomic.cpp
index 3adb2a7ad207f..2c9613deef744 100644
--- a/clang/lib/CodeGen/CGAtomic.cpp
+++ b/clang/lib/CodeGen/CGAtomic.cpp
@@ -590,6 +590,29 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr *E, Address Dest,
     llvm::LoadInst *Load = CGF.Builder.CreateLoad(Ptr);
     Load->setAtomic(Order, Scope);
     Load->setVolatile(E->isVolatile());
+
+    if (CGF.CGM.getCodeGenOpts().OptimizationLevel == 0) {
+      CGF.Builder.CreateStore(Load, Dest);
+      return;
+    }
+
+    QualType Ty = E->getValueType();
+    if (!Ty->isBooleanType()) {
+      CGF.Builder.CreateStore(Load, Dest);
+      return;
+    }
+
+    llvm::MDBuilder MDHelper(CGF.getLLVMContext());
+    llvm::APInt BooleanMin = llvm::APInt(CGF.getContext().getTypeSize(Ty), 0);
+    llvm::APInt BooleanEnd = llvm::APInt(CGF.getContext().getTypeSize(Ty), 2);
+
+    if (llvm::MDNode *RangeInfo =
+            MDHelper.createRange(BooleanMin, BooleanEnd)) {
+      Load->setMetadata(llvm::LLVMContext::MD_range, RangeInfo);
+      Load->setMetadata(llvm::LLVMContext::MD_noundef,
+                        llvm::MDNode::get(CGF.getLLVMContext(), {}));
+    }
+
     CGF.Builder.CreateStore(Load, Dest);
     return;
   }
diff --git a/clang/test/CodeGen/atomic-ops-load.c b/clang/test/CodeGen/atomic-ops-load.c
new file mode 100644
index 0000000000000..778a7ebdc2618
--- /dev/null
+++ b/clang/test/CodeGen/atomic-ops-load.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple riscv64 -O1 -emit-llvm %s -o - | FileCheck %s
+#include <stdbool.h>
+
+extern bool t1;
+bool test1(void) {
+// CHECK-LABEL: define{{.*}} i1 @test1
+// CHECK: load atomic i8, ptr @t1 monotonic, align 1, !range ![[$WS_RANGE:[0-9]*]], !noundef !{{[0-9]+}}
+// CHECK-NEXT: trunc nuw i8 %{{.*}} to i1
+// CHECK-NEXT: ret i1 %{{.*}}
+  return __atomic_load_n(&t1, __ATOMIC_RELAXED);
+}

efriedma-quic · 2025-04-02T22:23:00Z

clang/lib/CodeGen/CGAtomic.cpp

+    llvm::APInt BooleanEnd = llvm::APInt(CGF.getContext().getTypeSize(Ty), 2);
+
+    if (llvm::MDNode *RangeInfo =
+            MDHelper.createRange(BooleanMin, BooleanEnd)) {


Please refactor the code from CodeGenFunction::EmitLoadOfScalar, instead of reinventing the code to compute the range metadata.

efriedma-quic · 2025-04-02T22:23:53Z

clang/lib/CodeGen/CGAtomic.cpp

+    QualType Ty = E->getValueType();
+    if (!Ty->isBooleanType()) {
+      CGF.Builder.CreateStore(Load, Dest);
+      return;


Using an early return like this is weird; just stick a normal if statement around the code that creates the metadata.

…` helper to `EmitFromMemory` to allow adding `nuw` to `load` when safe.

efriedma-quic · 2025-04-10T17:11:02Z

I don't really understand what the new version of the patch is doing... instcombine can infer nuw on trunc if the operand has range metadata. There isn't any reason to duplicate that code.

janagor · 2025-04-10T19:48:50Z

I don't really understand what the new version of the patch is doing... instcombine can infer nuw on trunc if the operand has range metadata. There isn't any reason to duplicate that code.

The unoptimized version of the IR that is generated is as follows:

  %atomic-temp = alloca i8, align 1
  %0 = load atomic i8, ptr @t1 monotonic, align 1
  store i8 %0, ptr %atomic-temp, align 1
  %1 = load i8, ptr %atomic-temp, align 1
  %loadedv = trunc i8 %1 to i1
  ret i1 %loadedv

Lines 2-3 are generated by 'EmitAtomicOp' in CGAtomic, while CodeGenFunction::EmitLoadOfScalar adds range! only to line 4 when -O1. Lack of adding range! to 2nd line does not generate nuw at the end in trunc. From what I saw there were 2 ways to solve it: either add nuw the way I did it there, or add range! in EmitAtomicOp. I think in such case in order to no longer duplicate code would be to just make getRangeForLoadFromType a public method and use it for atomic load as well.

efriedma-quic · 2025-04-10T20:14:02Z

Oh, hmm, we have range metadata, but it gets killed by mem2reg. So instcombine could do the transform, but it runs too late. (In theory it could try to preserve range metadata; see convertMetadataToAssumes . But probably simpler here to just generate the markings.)

make getRangeForLoadFromType a public method and use it for atomic load as well

This seems fine.

…g `range!` metadata for atomic loads.

efriedma-quic · 2025-04-11T00:18:27Z

clang/lib/CodeGen/CGAtomic.cpp

@@ -590,6 +590,16 @@ static void EmitAtomicOp(CodeGenFunction &CGF, AtomicExpr *E, Address Dest,
    llvm::LoadInst *Load = CGF.Builder.CreateLoad(Ptr);
    Load->setAtomic(Order, Scope);
    Load->setVolatile(E->isVolatile());
+    QualType Ty = E->getValueType();
+    if (CGF.EmitScalarRangeCheck(Load, Ty, E->getExprLoc())) {
+    } else if (CGF.CGM.getCodeGenOpts().OptimizationLevel > 0) {


Can you refactor more of the code? Instead of just getRangeForLoadFromType, make a helper that calls EmitScalarRangeCheck() and add the metadata.

…ng range metadata. Made `getRangeForLoadFromType` private function as it was before f25e687.

efriedma-quic

LGTM

efriedma-quic · 2025-04-14T20:56:01Z

Not sure why automation didn't catch this, but:

⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo.
Please turn off Keep my email addresses private setting in your account.
See LLVM Discourse for more information.

janagor · 2025-04-14T21:19:52Z

Oh, I see, I changed it.

github-actions · 2025-04-14T21:26:31Z

@janagor Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!

…lvm#131476 (llvm#133546) Fixes llvm#131476. For `x86_64` it folds ``` movzbl t1(%rip), %eax andb $1, %al ``` into ``` movzbl t1(%rip), %eax ``` when run: `clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=x86_64`. But for riscv replaces: ``` lb a0, %lo(t1)(a0) andi a0, a0, 1 ``` with ``` lb a0, %lo(t1)(a0) zext.b a0, a0 ``` when run: `clang -S atomic-ops-load.c -o atomic-ops-load.s -O1 --target=riscv64`.

janagor added 3 commits March 29, 2025 00:49

[clang][CodeGen] Added llvm ir pre-commit test.

4581169

[clang][CodeGen] Added !range metadata to atomic load for bool.

852b691

Updated codestyle.

e42772b

llvmbot added clang Clang issues not falling into any other category clang:codegen IR generation bugs: mangling, exceptions, etc. labels Mar 29, 2025

janagor changed the title ~~Add range metadata for atomic load of boolean type. #131476~~ [clang][CodeGen] Add range metadata for atomic load of boolean type. #131476 Mar 31, 2025

efriedma-quic reviewed Apr 2, 2025

View reviewed changes

janagor added 2 commits April 4, 2025 11:23

Refactored early returns into normal if statement.

c95f16c

Reverted adding range! metadata from 852b691. Added `isSafeNUWTrunc…

ecc0f40

…` helper to `EmitFromMemory` to allow adding `nuw` to `load` when safe.

llvmbot added the backend:PowerPC label Apr 10, 2025

janagor and others added 3 commits April 10, 2025 12:25

Merge branch 'main' into add_range_metadata

97dc8df

Merge branch 'main' into add_range_metadata

91142fa

fixup! Merge branch 'main' into add_range_metadata

7e60e8f

janagor added 2 commits April 11, 2025 00:46

Reverted to state before ecc0f40.

df9c2bc

Exposed getRangeForLoadFromType as a public method to support addin…

f25e687

…g `range!` metadata for atomic loads.

efriedma-quic reviewed Apr 11, 2025

View reviewed changes

Created helper function for calling EmitScalarRangeCheck() and addi…

a348252

…ng range metadata. Made `getRangeForLoadFromType` private function as it was before f25e687.

efriedma-quic approved these changes Apr 11, 2025

View reviewed changes

efriedma-quic merged commit ff687af into llvm:main Apr 14, 2025
11 checks passed

janagor deleted the add_range_metadata branch April 27, 2025 16:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[clang][CodeGen] Add range metadata for atomic load of boolean type. #131476 #133546

[clang][CodeGen] Add range metadata for atomic load of boolean type. #131476 #133546

Uh oh!

janagor commented Mar 29, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Mar 29, 2025

Uh oh!

llvmbot commented Mar 29, 2025 •

edited

Loading

Uh oh!

efriedma-quic Apr 2, 2025

Uh oh!

efriedma-quic Apr 2, 2025

Uh oh!

efriedma-quic commented Apr 10, 2025

Uh oh!

janagor commented Apr 10, 2025 •

edited

Loading

Uh oh!

efriedma-quic commented Apr 10, 2025

Uh oh!

efriedma-quic Apr 11, 2025

Uh oh!

efriedma-quic left a comment

Uh oh!

efriedma-quic commented Apr 14, 2025

Uh oh!

janagor commented Apr 14, 2025

Uh oh!

Uh oh!

github-actions bot commented Apr 14, 2025

Uh oh!

Uh oh!

[clang][CodeGen] Add range metadata for atomic load of boolean type. #131476 #133546

[clang][CodeGen] Add range metadata for atomic load of boolean type. #131476 #133546

Uh oh!

Conversation

janagor commented Mar 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 29, 2025

Uh oh!

llvmbot commented Mar 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

efriedma-quic Apr 2, 2025

Choose a reason for hiding this comment

Uh oh!

efriedma-quic Apr 2, 2025

Choose a reason for hiding this comment

Uh oh!

efriedma-quic commented Apr 10, 2025

Uh oh!

janagor commented Apr 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

efriedma-quic commented Apr 10, 2025

Uh oh!

efriedma-quic Apr 11, 2025

Choose a reason for hiding this comment

Uh oh!

efriedma-quic left a comment

Choose a reason for hiding this comment

Uh oh!

efriedma-quic commented Apr 14, 2025

Uh oh!

janagor commented Apr 14, 2025

Uh oh!

Uh oh!

github-actions bot commented Apr 14, 2025

Uh oh!

Uh oh!

janagor commented Mar 29, 2025 •

edited

Loading

llvmbot commented Mar 29, 2025 •

edited

Loading

janagor commented Apr 10, 2025 •

edited

Loading