aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-diff
diff options
context:
space:
mode:
authorPaul Robinson <paul.robinson@sony.com>2021-07-27 13:33:52 -0700
committerPaul Robinson <paul.robinson@sony.com>2021-08-05 06:14:40 -0700
commit75aa3d520d53fb0d2a279736245ad255ec720a5b (patch)
tree4fec35ccb4543038bc37d4092217976368eb2ce6 /llvm/tools/llvm-diff
parent8d2a8ced00dc45605cb856845385d289e8cc45ed (diff)
downloadllvm-75aa3d520d53fb0d2a279736245ad255ec720a5b.zip
llvm-75aa3d520d53fb0d2a279736245ad255ec720a5b.tar.gz
llvm-75aa3d520d53fb0d2a279736245ad255ec720a5b.tar.bz2
Add a DIExpression const-folder to prevent silly expressions.
It's entirely possible (because it actually happened) for a bool variable to end up with a 256-bit DW_AT_const_value. This came about when a local bool variable was initialized from a bitfield in a 32-byte struct of bitfields, and after inlining and constant propagation, the variable did have a constant value. The sequence of optimizations had it carrying "i256" values around, but once the constant made it into the llvm.dbg.value, no further IR changes could affect it. Technically the llvm.dbg.value did have a DIExpression to reduce it back down to 8 bits, but the compiler is in no way ready to emit an oversized constant *and* a DWARF expression to manipulate it. Depending on the circumstances, we had either just the very fat bool value, or an expression with no starting value. The sequence of optimizations that led to this state did seem pretty reasonable, so the solution I came up with was to invent a DWARF constant expression folder. Currently it only does convert ops, but there's no reason it couldn't do other ops if that became useful. This broke three tests that depended on having convert ops survive into the DWARF, so I added an operator that would abort the folder to each of those tests. Differential Revision: https://reviews.llvm.org/D106915
Diffstat (limited to 'llvm/tools/llvm-diff')
0 files changed, 0 insertions, 0 deletions