[KeyInstr][Clang] Do stmt atom

See test comment for possible future improvement.

This patch is part of a stack that teaches Clang to generate Key Instructions
metadata for C and C++.

The Key Instructions project is introduced, including a "quick summary" section
at the top which adds context for this PR, here:
https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668

The feature is only functional in LLVM if LLVM is built with CMake flag
LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be removed.

The Clang-side work is demoed here:
https://github.com/llvm/llvm-project/pull/130943
This commit is contained in:
Orlando Cazalet-Hyams 2025-04-03 18:53:31 +01:00
parent eeee08d6d9
commit 2ee4d451f7
2 changed files with 42 additions and 1 deletions

View File

@ -1242,9 +1242,17 @@ void CodeGenFunction::EmitDoStmt(const DoStmt &S,
// As long as the condition is true, iterate the loop.
if (EmitBoolCondBranch) {
uint64_t BackedgeCount = getProfileCount(S.getBody()) - ParentCount;
Builder.CreateCondBr(
auto *I = Builder.CreateCondBr(
BoolCondVal, LoopBody, LoopExit.getBlock(),
createProfileWeightsForLoop(S.getCond(), BackedgeCount));
// Key Instructions: Emit the condition and branch as separate atoms to
// match existing loop stepping behaviour. FIXME: We could have the branch
// as the backup location for the condition, which would probably be a
// better experience (no jumping to the brace).
if (auto *I = dyn_cast<llvm::Instruction>(BoolCondVal))
addInstToNewSourceAtom(I, nullptr);
addInstToNewSourceAtom(I, nullptr);
}
LoopStack.pop();

View File

@ -0,0 +1,33 @@
// RUN: %clang -gkey-instructions -x c++ -std=c++17 %s -gmlt -S -emit-llvm -o - \
// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not atomRank
// RUN: %clang -gkey-instructions -x c %s -gmlt -S -emit-llvm -o - \
// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not atomRank
// Perennial quesiton: should the `dec` be in its own source atom or not
// (currently it is).
// Another question - we've made the cmp and br separate source atoms for
// now, to match existing behaviour in this case:
// 1. do {
// 2. something();
// 3. }
// 4. while (--A);
// Non key instruction behaviour is: 2, 4[, 3, 2, 4]+
// The cond br is associated with the brace on line 3 and the cmp is line 4;
// if they were in the same atom group we'd step just: 2, 3[, 2, 3]+
// FIXME: We could arguably improve the behaviour by making them the same
// group but having the cmp higher precedence, resulting in: 2, 4[, 2, 4]+.
void a(int A) {
// CHECK: %dec = add nsw i32 %0, -1, !dbg [[G1R2:!.*]]
// CHECK: store i32 %dec, ptr %A.addr{{.*}}, !dbg [[G1R1:!.*]]
// CHECK: %tobool = icmp ne i32 %dec, 0, !dbg [[G2R1:!.*]]
// CHECK: br i1 %tobool, label %do.body, label %do.end, !dbg [[G3R1:!.*]], !llvm.loop
do { } while (--A);
}
// CHECK: [[G1R2]] = !DILocation({{.*}}, atomGroup: 1, atomRank: 2)
// CHECK: [[G1R1]] = !DILocation({{.*}}, atomGroup: 1, atomRank: 1)
// CHECK: [[G2R1]] = !DILocation({{.*}}, atomGroup: 2, atomRank: 1)
// CHECK: [[G3R1]] = !DILocation({{.*}}, atomGroup: 3, atomRank: 1)