Even 1% globally is a significant regression for debug info that we aren’t actually going to query for common codebases. (Most code doesn’t normally contain either inline asm or warning/error attributes, and I’m not really convinced by other potential diagnostics.)
Currently, debug info is applied via IRBuilder::SetCurrentDebugLocation(), which is very convenient for applying debug info everywhere, but obviously less convenient for applying it selectively. You’d have to drive the computation a different way: make the code that constructs the relevant calls explicitly request debug info.
re:-Waggressive-loop-optimizations: In the past, we’ve intentionally avoided generating diagnostics from optimizations. This is based on feedback in the past from other optimizations: diagnostics produced the way tend to be produced inconsistently because they’re based on how code is optimized, and there are often unfixable false positives due to warnings on impossible codepaths. Instead, we’ve focused on a combination of static analysis and sanitizers. (This is also why _FORTIFY_SOURCE does not normally use “warning” or “error” attributes, outside the Linux kernel’s implementation.)