================
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -gkey-instructions -x c++ -std=c++17 %s
-debug-info-kind=line-tables-only -emit-llvm -o - \
+// RUN: | FileCheck %s --implicit-check-not atomGroup --implicit-check-not
atomRank
+
+// RUN: %clang_cc1 -gkey-instructions -x c %s
-debug-info-kind=line-tables-only -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]+.
----------------
jmorse wrote:
This sounds like the kind of FIXME that we should have a ticket for so that we
don't forget it -- having enough information to decide stepping behaviours like
this is great, and we should plan on improvements (once KIs have landed).
https://github.com/llvm/llvm-project/pull/134644
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
