Implementing GCOV in the new pass manager (r322126) I’m wondering whether the addition of a “StripSymbols(OnlyDebugInfo = true)” pass is needed - and maybe that functionality in general can be removed?
It was added, I believe, before we had the “NoDebug” style debug info, used specifically for profiling, optimization remarks, etc. So when this was implemented, stripping the debug info was probably necessary to avoid actually emitting debug info into the resulting object files.
This could be useful in an LTO like build, if you know the debug info is not needed at the LTO stage - strip it out at the end of the frontend compile to reduce the size of bitcode files.
So… does this seem relevant here? In general? (I haven’t looked at what other uses)
Totally happy to port the StripSymbols pass to the new pass manager if it seems like it’s useful/necessary.
Implementing GCOV in the new pass manager (r322126) I'm wondering whether the addition of a "StripSymbols(OnlyDebugInfo = true)" pass is needed - and maybe that functionality in general can be removed?
It was added, I believe, before we had the "NoDebug" style debug info, used specifically for profiling, optimization remarks, etc. So when this was implemented, stripping the debug info was probably necessary to avoid actually emitting debug info into the resulting object files.
This could be useful in an LTO like build, if you know the debug info is not needed at the LTO stage - strip it out at the end of the frontend compile to reduce the size of bitcode files.
You mean that for LTO scheduling an explicit StripSymbols pass is an advantage over just using the NoDebug, which only causes the baclkend to ignore it? But the debug info will probably be needed for optimization remarks during LTO time, wouldn't it?
So... does this seem relevant here? In general? (I haven't looked at what other uses)
As one datapoint, I didn't know we had StripSymbols(OnlyDebugInfo = true) as a pass (I only knew about the llvm::stripDebugInfo() functions). Grepping for other uses of StripSymbols and stripDebugInfo might be a good start.
-- adrian
Implementing GCOV in the new pass manager (r322126) I’m wondering whether the addition of a “StripSymbols(OnlyDebugInfo = true)” pass is needed - and maybe that functionality in general can be removed?
It was added, I believe, before we had the “NoDebug” style debug info, used specifically for profiling, optimization remarks, etc. So when this was implemented, stripping the debug info was probably necessary to avoid actually emitting debug info into the resulting object files.
This could be useful in an LTO like build, if you know the debug info is not needed at the LTO stage - strip it out at the end of the frontend compile to reduce the size of bitcode files.
You mean that for LTO scheduling an explicit StripSymbols pass is an advantage over just using the NoDebug, which only causes the baclkend to ignore it? But the debug info will probably be needed for optimization remarks during LTO time, wouldn’t it?
Right - though you could be doing a build that doesn’t have remarks enabled, but wanted debug info locations for something that’s frontend-only? I don’t know the full diversity of uses of NoDebug debug info, but could imagine there might be uses (not sure if there are current uses - could be future uses, but that’s nothing to worry much about/design for of course) that only need it for the frontend compile.
So… does this seem relevant here? In general? (I haven’t looked at what other uses)
As one datapoint, I didn’t know we had StripSymbols(OnlyDebugInfo = true) as a pass (I only knew about the llvm::stripDebugInfo() functions). Grepping for other uses of StripSymbols and stripDebugInfo might be a good start.
nod
Implementing GCOV in the new pass manager (r322126) I'm wondering whether
the addition of a "StripSymbols(OnlyDebugInfo = true)" pass is needed - and
maybe that functionality in general can be removed?
It was added, I believe, before we had the "NoDebug" style debug info,
used specifically for profiling, optimization remarks, etc. So when this
was implemented, stripping the debug info was probably necessary to avoid
actually emitting debug info into the resulting object files.
Correct. I'm not familiar with NoDebug beyond your description in this
thread, but it sounds like the right thing to use now.
This could be useful in an LTO like build, if you know the debug info is