Open dwblaikie opened 5 years ago
There are technically certain cases involving globals with an "undef" initializer where encoding the global as a constant could be misleading... but it's probably better than the alternative of discarding the debug info. Not sure if it's practical to trigger from clang at the moment.
This is probably trivial to fix if there's some helper for transforming the debug info of a global in the way you're suggesting.
I have a decent amount of familiarity with SCCP, so I'll try to take a look, but no promises.
Extended Description
Given this code:
static int x = 3; int z() { return x; }
Unoptimized, the resulting DWARF describes the location of 'x'.
Once optimized by SCCP, the LLVM IR is not updated with a description of the constant value of 'x', the value is lost entirely.
Looks like down in the final loop (line ~2140) in SCCP.cpp, that's deleting globals - it could check if there's debug info attached to the GlobalVariable, and rewrite it to a constant description using I->second.getConstant(), if the constant is of a type (int or float? I think are the ones currently supported) that can be encoded as a constant in the debug info metadata at the moment.
This may be incorrect in cases where this optimization fires & due to previous passes eliminating dead stores to the variable (in which case the dead stores wouldn't be reflected - though I suppose at that point describing the location of the variable as being in the global is just as erroneous), but it looks like, at least if you complicate the case by adding "x = 7;" to z() before the return, it's not SCCP that optimizes away the GlobalVariable, but GlobalOpt. So maybe fixing SCCP isn't an issue in this way.