Mircea TrofinandOwen Rodley
39dcb0ff91
This reverts #201194, thus relanding @orodley's PR #184065 (and #200323): > This allows us to keep GUIDs consistent across compilation phases which may change the name or linkage type. > See https://discourse.llvm.org/t/rfc-keep-globalvalue-guids-stable/84801 The CFI issues that triggered the original revert are fixed by #201370, together with the addressing of the TODOs in `LowerTypeTests.cpp` left in the latter. The [graphite diff](https://app.graphite.com/github/pr/llvm/llvm-project/201849/Reland-%23184065) between this change's V1 and V2 shows what's been added: - the `TODO`s from #201370 are done - in LowerTypeTests.cpp, passing `!guid` when creating a new declaration and when converting a definition to a declaration. - `llvm/test/Transforms/LowerTypeTests/export-icall.ll` tests also the above def->decl conversion - removed `test/Analysis/CtxProfAnalysis/flatten-prethinlink-requires-guid-metadata.ll` introduced in #194383 (this was between the revert and this PR), as now the general expectation is that GUID assignment happens appropriately and all passes use `getGUID`, so there's no reason for `CtxProfAnalysis` to do something different. Currently, we reassign GUIDs when CFI promotes internal linkage symbols, which is counter to the goal of the RFC. This is addressed in PR #203171. The reason for this split fix can be explained on `compiler-rt/test/cfi/icall/wrong-signature-mixed-lto.c`. Here, a module with the exact same source path is compiled twice, under different conditional compilation, to produce 2 objects. Each object defines an internal linkage symbol with the same name (this is `install_trap_loop_detection` from `compiler-rt/test/cfi/trap_loop_signal_handler.inc` which is `-include`\-d by both - see how `%clang_cfi` is defined). The ThinLTO GUID of this symbol will be the same. Its name won't be - because CFI promotes it and renames it using a hash that is based on the IR Module content (rather than the source path). During thinlink, `LTO::addThinLTO`will mark each of the 2 exported symbols as prevailing in their corresponding modules. But that is done by associating their GUID to the module. So whichever comes last wins. The other symbol will be marked available externally and its body DCEd later in backend. But each module will refer to its copy of `install_trap_loop_detection`, and so we end up with a linker error. As mentioned, the fix is in PR #203171, and this relanding PR just maintains the existing ThinLTO behavior by rewriting the GUIDs. Since we haven't yet leveraged the GUID mechanics for e.g. simplifying PGO, this aspect of this change is essentially NFC. Co-authored-by: Owen Rodley <orodley@google.com>
124 lines
4.2 KiB
LLVM
124 lines
4.2 KiB
LLVM
; Test to check the callgraph in summary when there is PGO
|
|
; RUN: opt -module-summary %s -o %t.o
|
|
; RUN: llvm-bcanalyzer -dump %t.o | FileCheck %s
|
|
; RUN: opt -module-summary %p/Inputs/thinlto-function-summary-callgraph-sample-profile-summary.ll -o %t2.o
|
|
; RUN: llvm-lto -thinlto -o %t3 %t.o %t2.o
|
|
; RUN: llvm-bcanalyzer -dump %t3.thinlto.bc | FileCheck %s --check-prefix=COMBINED
|
|
|
|
|
|
; CHECK: <SOURCE_FILENAME
|
|
; "hot_function"
|
|
; CHECK-NEXT: <GUIDLIST
|
|
; CHECK-NEXT: <FUNCTION op0=0 op1=12
|
|
; "hot1"
|
|
; CHECK-NEXT: <FUNCTION op0=12 op1=4
|
|
; "hot2"
|
|
; CHECK-NEXT: <FUNCTION op0=16 op1=4
|
|
; "hot3"
|
|
; CHECK-NEXT: <FUNCTION op0=20 op1=4
|
|
; "hot4"
|
|
; CHECK-NEXT: <FUNCTION op0=24 op1=5
|
|
; "cold"
|
|
; CHECK-NEXT: <FUNCTION op0=29 op1=5
|
|
; "none1"
|
|
; CHECK-NEXT: <FUNCTION op0=34 op1=5
|
|
; "none2"
|
|
; CHECK-NEXT: <FUNCTION op0=39 op1=5
|
|
; "none3"
|
|
; CHECK-NEXT: <FUNCTION op0=44 op1=5
|
|
; CHECK-NEXT: <FUNCTION op0=49 op1=5
|
|
|
|
; CHECK-LABEL: <GLOBALVAL_SUMMARY_BLOCK
|
|
; CHECK-NEXT: <VERSION
|
|
; CHECK-NEXT: <FLAGS
|
|
; CHECK-NEXT: <VALUE_GUID {{.*}} op0=27 op1=0 op2=123/>
|
|
; op4=none1 op6=hot1 op8=cold1 op10=none2 op12=hot2 op14=cold2 op16=none3 op18=hot3 op20=cold3 op22=123
|
|
; CHECK-NEXT: <PERMODULE_PROFILE {{.*}} op7=7 op8=0 op9=1 op10=3 op11=4 op12=1 op13=8 op14=0 op15=2 op16=3 op17=5 op18=1 op19=9 op20=0 op21=3 op22=3 op23=6 op24=1 op25=27 op26=4/>
|
|
; CHECK-NEXT: </GLOBALVAL_SUMMARY_BLOCK>
|
|
|
|
; CHECK: <STRTAB_BLOCK
|
|
; CHECK-NEXT: blob data = 'hot_functionhot1hot2hot3cold1cold2cold3none1none2none3{{.*}}'
|
|
|
|
; COMBINED: <GLOBALVAL_SUMMARY_BLOCK
|
|
; COMBINED-NEXT: <VERSION
|
|
; COMBINED-NEXT: <FLAGS
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <VALUE_GUID
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: <COMBINED_PROFILE {{.*}} op9=[[NONE1:.*]] op10=0 op11=[[HOT1:.*]] op12=3 op13=[[COLD1:.*]] op14=1 op15=[[NONE2:.*]] op16=0 op17=[[HOT2:.*]] op18=3 op19=[[COLD2:.*]] op20=1 op21=[[NONE3:.*]] op22=0 op23=[[HOT3:.*]] op24=3 op25=[[COLD3:.*]] op26=1/>
|
|
; COMBINED-NEXT: <COMBINED_PROFILE abbrevid=
|
|
; COMBINED-NEXT: </GLOBALVAL_SUMMARY_BLOCK>
|
|
|
|
|
|
; ModuleID = 'thinlto-function-summary-callgraph.ll'
|
|
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
|
|
target triple = "x86_64-unknown-linux-gnu"
|
|
|
|
; This function have high profile count, so entry block is hot.
|
|
define void @hot_function(i1 %a, i1 %a2) !prof !20 {
|
|
entry:
|
|
call void @none1()
|
|
call void @hot1(), !prof !15
|
|
call void @cold1(), !prof !16
|
|
br i1 %a, label %Cold, label %Hot, !prof !41
|
|
Cold: ; 1/1000 goes here
|
|
call void @none2()
|
|
call void @hot2(), !prof !15
|
|
call void @cold2(), !prof !16
|
|
br label %exit
|
|
Hot: ; 999/1000 goes here
|
|
call void @none3()
|
|
call void @hot3(), !prof !15
|
|
call void @cold3(), !prof !16
|
|
br label %exit
|
|
exit:
|
|
ret void
|
|
}
|
|
|
|
declare void @hot1() #1
|
|
declare void @hot2() #1
|
|
declare void @hot3() #1
|
|
declare void @cold1() #1
|
|
declare void @cold2() #1
|
|
declare void @cold3() #1
|
|
declare void @none1() #1
|
|
declare void @none2() #1
|
|
declare void @none3() #1
|
|
|
|
!41 = !{!"branch_weights", i32 1, i32 1000}
|
|
|
|
!llvm.module.flags = !{!1}
|
|
!20 = !{!"function_entry_count", i64 110, i64 123}
|
|
|
|
!1 = !{i32 1, !"ProfileSummary", !2}
|
|
!2 = !{!3, !4, !5, !6, !7, !8, !9, !10}
|
|
!3 = !{!"ProfileFormat", !"SampleProfile"}
|
|
!4 = !{!"TotalCount", i64 10000}
|
|
!5 = !{!"MaxCount", i64 10}
|
|
!6 = !{!"MaxInternalCount", i64 1}
|
|
!7 = !{!"MaxFunctionCount", i64 1000}
|
|
!8 = !{!"NumCounts", i64 3}
|
|
!9 = !{!"NumFunctions", i64 3}
|
|
!10 = !{!"DetailedSummary", !11}
|
|
!11 = !{!12, !13, !14}
|
|
!12 = !{i32 10000, i64 100, i32 1}
|
|
!13 = !{i32 999000, i64 100, i32 1}
|
|
!14 = !{i32 999999, i64 1, i32 2}
|
|
!15 = !{!"branch_weights", i32 100}
|
|
!16 = !{!"branch_weights", i32 1}
|