-
Notifications
You must be signed in to change notification settings - Fork 14.3k
InstProfiling: Give the name to profc_bias. NFC. #95587
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@llvm/pr-subscribers-pgo @llvm/pr-subscribers-llvm-transforms Author: NAKAMURA Takumi (chapuni) ChangesFull diff: https://github.com/llvm/llvm-project/pull/95587.diff 3 Files Affected:
diff --git a/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp b/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
index 0c79eaa812b5f..6fd9468f7905b 100644
--- a/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
+++ b/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
@@ -926,10 +926,10 @@ Value *InstrLowerer::getCounterAddress(InstrProfCntrInstBase *I) {
if (TT.supportsCOMDAT())
Bias->setComdat(M.getOrInsertComdat(Bias->getName()));
}
- BiasLI = EntryBuilder.CreateLoad(Int64Ty, Bias);
+ BiasLI = EntryBuilder.CreateLoad(Int64Ty, Bias, "profc_bias");
}
auto *Add = Builder.CreateAdd(Builder.CreatePtrToInt(Addr, Int64Ty), BiasLI);
- return Builder.CreateIntToPtr(Add, Addr->getType());
+ return Builder.CreateIntToPtr(Add, Addr->getType(), "profc_addr");
}
Value *InstrLowerer::getBitmapAddress(InstrProfMCDCTVBitmapUpdate *I) {
diff --git a/llvm/test/Instrumentation/InstrProfiling/runtime-counter-relocation.ll b/llvm/test/Instrumentation/InstrProfiling/runtime-counter-relocation.ll
index 44a2efd4a959a..53b1e4918e8d1 100644
--- a/llvm/test/Instrumentation/InstrProfiling/runtime-counter-relocation.ll
+++ b/llvm/test/Instrumentation/InstrProfiling/runtime-counter-relocation.ll
@@ -8,16 +8,16 @@ target triple = "x86_64-unknown-linux-gnu"
; RELOC: @__llvm_profile_counter_bias = linkonce_odr hidden global i64 0, comdat
; CHECK-LABEL: define void @foo
-; CHECK-NEXT: %pgocount = load i64, ptr @__profc_foo
-; CHECK-NEXT: %1 = add i64 %pgocount, 1
-; CHECK-NEXT: store i64 %1, ptr @__profc_foo
+; CHECK-NEXT: %[[PGOCOUNT:.+]] = load i64, ptr @__profc_foo
+; CHECK-NEXT: %[[PGOCOUNTINC:.+]] = add i64 %[[PGOCOUNT]], 1
+; CHECK-NEXT: store i64 %[[PGOCOUNTINC]], ptr @__profc_foo
; RELOC-LABEL: define void @foo
-; RELOC-NEXT: %1 = load i64, ptr @__llvm_profile_counter_bias
-; RELOC-NEXT: %2 = add i64 ptrtoint (ptr @__profc_foo to i64), %1
-; RELOC-NEXT: %3 = inttoptr i64 %2 to ptr
-; RELOC-NEXT: %pgocount = load i64, ptr %3
-; RELOC-NEXT: %4 = add i64 %pgocount, 1
-; RELOC-NEXT: store i64 %4, ptr %3
+; RELOC-NEXT: %[[BIAS:.+]] = load i64, ptr @__llvm_profile_counter_bias
+; RELOC-NEXT: %[[PROFC_BIAS:.+]] = add i64 ptrtoint (ptr @__profc_foo to i64), %[[BIAS]]
+; RELOC-NEXT: %[[PROFC_ADDR:.+]] = inttoptr i64 %[[PROFC_BIAS]] to ptr
+; RELOC-NEXT: %[[PGOCOUNT:.+]] = load i64, ptr %[[PROFC_ADDR]]
+; RELOC-NEXT: %[[PGOCOUNTINC:.+]] = add i64 %[[PGOCOUNT]], 1
+; RELOC-NEXT: store i64 %[[PGOCOUNTINC]], ptr %[[PROFC_ADDR]]
define void @foo() {
call void @llvm.instrprof.increment(ptr @__profn_foo, i64 0, i32 1, i32 0)
ret void
diff --git a/llvm/test/Transforms/PGOProfile/counter_promo_with_bias.ll b/llvm/test/Transforms/PGOProfile/counter_promo_with_bias.ll
index c489a9f8eea84..7b1da764e776e 100644
--- a/llvm/test/Transforms/PGOProfile/counter_promo_with_bias.ll
+++ b/llvm/test/Transforms/PGOProfile/counter_promo_with_bias.ll
@@ -6,7 +6,7 @@ target triple = "x86_64-unknown-linux-gnu"
define void @foo(i1 %c) {
entry:
-; CHECK: %[[BIAS:[0-9]+]] = load i64, ptr @__llvm_profile_counter_bias
+; CHECK: %[[BIAS:.+]] = load i64, ptr @__llvm_profile_counter_bias
br label %while.cond
while.cond: ; preds = %land.rhs, %while.cond.preheader
|
BiasLI = EntryBuilder.CreateLoad(Int64Ty, Bias, "profc_bias"); | ||
} | ||
auto *Add = Builder.CreateAdd(Builder.CreatePtrToInt(Addr, Int64Ty), BiasLI); | ||
return Builder.CreateIntToPtr(Add, Addr->getType()); | ||
return Builder.CreateIntToPtr(Add, Addr->getType(), "profc_addr"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember who said this or if it still applies, but I've been told that these names can increase compile times. Can you test some that the build time of some moderately large module isn't regressed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks to suggest a consideration. Let me speak my justifications.
Generally, this is just for instrumentation mode. So, we could consider how much compilation time would be impacted in instrumentation modes. Named Insts will have extra cost (ex. adding suffixes) when they (Insts) are copied or propagated in transformations. In contrast, Insts' users won't have any costs since using just refers to Insts. I haven't measured yet.
Re. profc_bias
, I can justify. It will be merged to the single Inst with optimizations. (#95588)
The named Value will help readability for looking into larger funcs.
Re. profc_addr
, it is referred in two places with load/store, in one place with atomic rmw. (will become two places when TATAS is introduced) I guess it won't enhance readability so much, since the scope of profc_addr
is small. That said, I think it's good thing to mark key Values (Insts) named..
An example from #95588, with optimized
With names;
define void @foo() {
%profc_bias = load i64, ptr @__llvm_profile_counter_bias, align 8, !invariant.load !0
%1 = add i64 ptrtoint (ptr @__profc_foo to i64), %profc_bias
%profc_addr = inttoptr i64 %1 to ptr
%pgocount = load i64, ptr %profc_addr, align 8
%2 = add i64 %pgocount, 1
store i64 %2, ptr %profc_addr, align 8
%3 = add i64 ptrtoint (ptr @__profc_bar to i64), %profc_bias
%profc_addr.i = inttoptr i64 %3 to ptr
%pgocount.i = load i64, ptr %profc_addr.i, align 8
%4 = add i64 %pgocount.i, 1
store i64 %4, ptr %profc_addr.i, align 8
ret void
}
W/o names;
define void @foo() {
%1 = load i64, ptr @__llvm_profile_counter_bias, align 8, !invariant.load !0
%2 = add i64 ptrtoint (ptr @__profc_foo to i64), %1
%3 = inttoptr i64 %2 to ptr
%pgocount = load i64, ptr %3, align 8
%4 = add i64 %pgocount, 1
store i64 %4, ptr %3, align 8
%5 = add i64 ptrtoint (ptr @__profc_bar to i64), %1
%6 = inttoptr i64 %5 to ptr
%pgocount.i = load i64, ptr %6, align 8
%7 = add i64 %pgocount.i, 1
store i64 %7, ptr %6, align 8
ret void
}
Could we suppose it would justify the microcost for naming a few Insts per region?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you decide to leave out profc_addr
, we might also want to leave out pgocount
since the scope is small and the instructions are fairly simple. I can understand wanting profc_bias
since those instructions are less obvious.
I just realized there are a few words on this naming in the programmer's manual. It doesn't have guidance on when and how to name these variables, which is unfortunate.
https://llvm.org/docs/ProgrammersManual.html#creating-and-inserting-new-instructions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried removing pgocount
. It was too intrusive for tests.
@ellishg At the moment, I've made this dedicated to "profc_bias". I'm afraid that "profc_bias" would confuse since it is similar to other "profc" structure. I will introduce "bias value for bitmap" as "profbm_bias" later. I will create another request for "profc_addr" and "pgocount" later. |
Conflicts: llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
No description provided.