hoy added a comment. In D86502#2245734 <https://reviews.llvm.org/D86502#2245734>, @wmi wrote:
> In D86502#2245578 <https://reviews.llvm.org/D86502#2245578>, @hoy wrote: > >> In D86502#2245460 <https://reviews.llvm.org/D86502#2245460>, @wmi wrote: >> >>>> The early instrumentation also allows the inliner to duplicate probes for >>>> inlined instances. When a probe along with the other instructions of a >>>> callee function are inlined into its caller function, the GUID of the >>>> callee function goes with the probe. This allows samples collected on >>>> inlined probes to be reported for the original callee function. >>> >>> Just get a question from reading the above. Suppose `A` only has one BB and >>> the BB has one PseudoProbe in it. If function `A` is inlined into `B1` and >>> `B2` and both `B1` and `B2` inlined into `C`, the PseudoProbe from `A` will >>> have two copies in `C` both carrying GUID of `A`. How the samples collected >>> from `A` inlined into `B1` inlined into `C` are categorized differently >>> from `A` inlined into `B2` inlined into `C`, especially when debug >>> information is not enabled (so no inline stack information in the binary)? >> >> This is a very good question. Inlined functions are differentiated by their >> original callsites. A pseudo probe is allocated for each callsite in the >> `SampleProfileProbe` pass. Nested inlining will produce a stack of pseudo >> probes, similar with the Dwarf inline stack. The work is not included in the >> first set of patches. > > Thanks, then how does the pseudo probe for a callsite after inline to > represent the inline scope it covers? It is represented by the dwarf inline stack for that inlined pseudo probe. I'm about to send out a patch for it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86502/new/ https://reviews.llvm.org/D86502 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
