In D147777 emitDbgAssign was fixed to discard assignments which touched any bits outside the bounds of a variable. This patch changes emitDbgAssign to discard assignments which touch bits only outside the variable bounds, and creates a truncated fragment expression for stores partially overlapping the variable. This is necessary because the alloca is interpreted as a store (of undef), meaning without this patch emitDbgAssign would discard the inital dbg.assign for a variable that is smaller than the alloca.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM with some fairly standard nits
llvm/lib/IR/DebugInfo.cpp | ||
---|---|---|
1854–1865 | Can we assert this, for when it likely changes in the future and we forget this code? | |
1860 | Seeing how both inputs are unsigned and one argument is zero, isn't this guaranteed to always be FragStartBit? (Could produce a warning somewhere) | |
llvm/test/DebugInfo/Generic/assignment-tracking/declare-to-assign/var-not-alloca-sized.ll | ||
5–7 | "looks right" is a bit too vague when someone has to update this test in the future, spelling it out a bit more would be better. |
Thanks
+ Address nits + respond in-line
llvm/lib/IR/DebugInfo.cpp | ||
---|---|---|
1854–1865 | That info would come from the VarRecord which doesn't yet support any kind of offset. We could add a "dummy" field to that struct and then assert that it is zero here, but I'm not sure that's much better than the VarStartBit = 0; below. wdyt? | |
1860 | Yeah that's right, I was setting up for a future where it's not always zero. But good point about potential warning. I've replaced the line with a FIXME. |
Seeing how both inputs are unsigned and one argument is zero, isn't this guaranteed to always be FragStartBit? (Could produce a warning somewhere)