I often run llvm-reduce on IR that contains debug info, this prevents an
extra step of opt -passes=strip I do every time and will result in a
lot less invalid reductions around debug metadata.
Details
- Reviewers
arsenm dblaikie - Commits
- rG0fbb261536a4: [llvm-reduce] Attempt to strip debug info
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/tools/llvm-reduce/deltas/StripDebugInfo.cpp | ||
---|---|---|
22 | not sure if this is the best way to detect presence of debug info |
the existing di-metadata pass is very specific, it only tries to remove array entries debug info metadata arrays. it doesn't do anything with !dbg attached to instructions, the corresponding DI metadata nodes, the global named !llvm.dbg.* named metadata, and dbg intrinsics
But the metadata reduction looks at individual instructions. Doesn't di-metadata + metadata cover this?
I'm not sure that di-metadata can handle all types of debug info structures (I think I've seen cases where not all debug info is removed even though the striped IR still is interesting, although I'm having a hard time remembering a specific example). But even if it did, we get lots of invalid reductions (due to various verifier constraints) that would be avoided if we just stripped everything to begin with, speeding things up a lot.
I don't really know enough about debug info to dispute this, but I don't find working around invalid reductions in the existing passes a compelling reason to special case eliminating all the debug info
llvm/tools/llvm-reduce/deltas/StripDebugInfo.cpp | ||
---|---|---|
25 | Looks like this also strips function/global variable names and register names - any chance we don't want to strip those too? Should we call this llvm-reduce pass "StripSymbols" rather than "stripDebugInfo" to be consistent with the underlying pass and its slightly different/broader semantics? |
there are random constraints on debug info metadata, e.g. https://reviews.llvm.org/D135492. while it's possible to handle all of these in all the different passes, I don't think it's necessarily worth the effort if most of the time debug info doesn't matter anyway
not sure if this is the best way to detect presence of debug info