[clang] [llvm] [DebugInfo] Emit DW_AT_const_value for constexpr array static members (PR #182442)

[Shivam Kunwar via cfe-commits]

phyBrackets wrote:

> > but I think DW_AT_const_value helps in cases where it doesn't for eg if the variable is never odr used, the linker can discard it entirely, and there would be no memory location to read, and remote debugging where reading target memory is expensive or unavailable.
> 
> `[[gnu::used]]` can prevent the deduplication if desired and expensive target memory reads I'm personally not sure is a strong argument for adding more debug-info. It'd be good to have at least a known use-case of the constant being optimized out by Clang in a way which makes inspecting it in the debugger not work. I'm not claiming that there are no cases like that, but it'd be at least a valid motivator.
> 
> Re. GCC compatibility. Yes compatibility is a good goal, but in my opinion not if that's the only goal.
> 
> And yea some DWARF consumers probably do care about debug-info size increase, so running `bloaty <clang object files after patch> -- <clang object files before patch>` would be helpful. But probably best to hold off until people think this is something worth pursuing

Thanks for explanation. Few things that I found regarding this, that might  make sense, clang already emits `DW_AT_const_value` for `static constexpr int` and `static constexpr float` members, and this patch would be extending the same treatment to arrays of those element types, if it wasn't worth the dwarf cost for scalars, it wouldn't be added.

Relatedly, @dwblaikie filed https://github.com/llvm/llvm-project/issues/102676 about intermittently missing `DW_AT_const_value` for scalar constexpr static members and labeled it wrong-debug, suggesting the community considers emitting these values the correct behavior.

on `[[gnu::used]]` , on elf targets it actually doesn't prevent linker section GC , and requiring source annotations to preserve debuggability isn't great. 

But open to other feedbacks, and maybe if we all agree we could have a discussion over discourse.

https://github.com/llvm/llvm-project/pull/182442