[PATCH] D48408: [Debugify] Diagnose mis-sized dbg.values

[Vedant Kumar via Phabricator via llvm-commits]

vsk planned changes to this revision.
vsk added a comment.

I think I need to bring back the exception for integers. Adrian pointed out (in https://reviews.llvm.org/D48331) that DI variables with a smaller size than a dbg.value operand implicitly use the lower bits. This works for the integer case.

In https://reviews.llvm.org/D48408#1143487, @probinson wrote:

> Hm.  DataLayout is willing to report back one of three possible sizes: the size of a value; the size written by a store; and the stride of an array.  getTypeAllocSize() returns the third of these, which would include alignment padding as needed.
>  Is that really the value size we expect from dbg.value?


Oh I see, thanks for pointing this distinction out.

In the example I shared above, at -O0, the stack slot for the x86_fp80 is 128 bits in size (https://godbolt.org/g/B89MwC). LLVM generates a ST_FP80m to convert the fp80 into "double extended-precision floating-point format", which it then stores into this slot. So I think 128 bits makes sense as the size: anything else could confuse the debugger about what's on the stack. I'm not sure how we'd support debugging fp80's which are "in" the FPU, i.e which are not spilled. FWIW, we tend to spill (-O2, https://godbolt.org/g/uwpMYY).

In general then, I think getAllocSizeInBits is the appropriate size to use, because it captures the fact that conversions may be needed to place the value in a stack slot.


https://reviews.llvm.org/D48408