Skip to content

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Jun 19, 2024
Merged

InstProfiling: Give the name to profc_bias. NFC. #95587

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
59a8113
InstProfiling: Give names to profc_bias and profc_addr. NFC.
chapuni Jun 14, 2024
212f705
Exlude "profc_addr" for now.
chapuni Jun 18, 2024
655da6a
Merge branch 'main' into mcdc/profc_name
chapuni Jun 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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");
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor Author

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.

}

Value *InstrLowerer::getBitmapAddress(InstrProfMCDCTVBitmapUpdate *I) {
Expand Down
18 changes: 9 additions & 9 deletions llvm/test/Instrumentation/InstrProfiling/runtime-counter-relocation.ll
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion llvm/test/Transforms/PGOProfile/counter_promo_with_bias.ll
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Loading