search for: pr21910

...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 { > unreachable > } > !0 = !MDSubprogram(name: "foo", function: voi...

...e:` chains terminate at an `MDCompileUnit` and drop "scope"-ness of `MDFile`, and (5) finally drop the `subprograms:` field from `MDCompileUnit`. But I'm not confident about step 4 yet.) > >> 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 { >> unreachable >> } >> !0 = !MDSubprogram(name: "f...

...debug info necessarily /describes/ the source the user wrote, so it's always going to be more verbose, but maybe it's achievable) Yeah, I think this is a great idea. > > > > > >> 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 { > >> unreachable > >> } > >>...

...DCompileUnit` and drop "scope"-ness > of `MDFile`, and (5) finally drop the `subprograms:` field from > `MDCompileUnit`. But I'm not confident about step 4 yet.) > > > > >> 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 { > >> unreachable > >> } > >>...