search for: mdsubrogram

...!0 = !{i32 987} That will be great. Would it be better if the type is i64? We really want to avoid an overflow if possible. What is the type for the raw profile data for region(0)? Ivan > > 2. In debug info, we repeatedly build up a map from `Function` to the > canonical `MDSubrogram` for it. Keeping this mapping accurate takes > subtle logic in `lib/Linker` (see PR21910/PR22792) and it's > expensive to compute and maintain. Attaching it directly to the > `Function` designs away the problem. > > define void @foo() !dbg !0 { >...

...t - can't say I know anything about that. > >> >> define void @foo() !prof !0 { >> unreachable >> } >> !0 = !{i32 987} >> >> 2. In debug info, we repeatedly build up a map from `Function` to the >> canonical `MDSubrogram` for it. > > Sounds great - I'd imagine this working somewhat like the way I've > made implicit special members & other non-standard members of class > types work in the debug info metadata, which is to say that the > children reference the parent, but the parent doesn...

...at. > > > >> > >> define void @foo() !prof !0 { > >> unreachable > >> } > >> !0 = !{i32 987} > >> > >> 2. In debug info, we repeatedly build up a map from `Function` to the > >> canonical `MDSubrogram` for it. > > > > Sounds great - I'd imagine this working somewhat like the way I've > > made implicit special members & other non-standard members of class > > types work in the debug info metadata, which is to say that the > > children reference the parent...

...at. > > > >> > >> define void @foo() !prof !0 { > >> unreachable > >> } > >> !0 = !{i32 987} > >> > >> 2. In debug info, we repeatedly build up a map from `Function` to the > >> canonical `MDSubrogram` for it. > > > > Sounds great - I'd imagine this working somewhat like the way I've > > made implicit special members & other non-standard members of class > > types work in the debug info metadata, which is to say that the > > children reference the parent...