search for: mdsubprogram

...syntax pulls the tag out of the current header-string, calls >> the rest of the header "fields", and includes the metadata operands >> in "operands". >> >> 5. Incrementally create subclasses of `DebugMDNode`, such as >> `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the >> "fields" and "operands" catch-alls with explicit names for each >> operand. >> >> Proposed assembly syntax: >> >> !7 = metadata !MDSubprogram(line: 45, name: "foo", displayName: &qu...

...handle: i32* @global_var) This syntax pulls the tag out of the current header-string, calls the rest of the header "fields", and includes the metadata operands in "operands". 5. Incrementally create subclasses of `DebugMDNode`, such as `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the "fields" and "operands" catch-alls with explicit names for each operand. Proposed assembly syntax: !7 = metadata !MDSubprogram(line: 45, name: "foo", displayName: "foo",...

...he current header-string, calls > >> the rest of the header "fields", and includes the metadata operands > >> in "operands". > >> > >> 5. Incrementally create subclasses of `DebugMDNode`, such as > >> `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the > >> "fields" and "operands" catch-alls with explicit names for each > >> operand. > >> > >> Proposed assembly syntax: > >> > >> !7 = metadata !MDSubprogram(line: 45, name:...

...) 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: void ()* @foo) > >> > >> Thoughts? > >> > >> Moving onto implementation, I'd provide the same generic API that > >> `Instruction` has, and wouldn't bother with the "fast path" API for > >> `!dbg...

...; > This syntax pulls the tag out of the current header-string, calls > the rest of the header "fields", and includes the metadata operands > in "operands". > > 5. Incrementally create subclasses of `DebugMDNode`, such as > `MDCompileUnit` and `MDSubprogram`. Sub-classed nodes replace the > "fields" and "operands" catch-alls with explicit names for each > operand. > > Proposed assembly syntax: > > !7 = metadata !MDSubprogram(line: 45, name: "foo", displayName: > "foo", &...

...`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: void ()* @foo) >> >> Thoughts? >> >> Moving onto implementation, I'd provide the same generic API that >> `Instruction` has, and wouldn't bother with the "fast path" API for >> `!dbg`. Moreover, the generic pa...

...gt; 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: void ()* @foo) > > Thoughts? > > Moving onto implementation, I'd provide the same generic API that > `Instruction` has, and wouldn't bother with the "fast path" API for > `!dbg`. Moreover, the generic path wouldn't be slow....

...l a custom type anyway, I might as well go full hog: - Make the "large" vector `std::pair<unsigned, TrackingMDNodeRef>`. - Reserve the "small" vector for the `!dbg` tag. - Add custom hooks for `MetadataTracking` for the "small" version, allowing a raw `MDSubprogram*` instead of a `TrackingMDNodeRef`. This would squeeze it all into 8B, but require the "large" vector whenever we have a non-`!dbg` attachment (even if there's just one attachment). Another possible opportunity here: bringing it down to pointer size means we could share the impleme...