[PATCH] D16867: Debug Info: Allow SROAed complex floating point types to be described by constants

[Paul Robinson via llvm-commits]

probinson added inline comments.

================
Comment at: test/DebugInfo/ARM/sroa-complex.ll:16
@@ +15,3 @@
+  ; CHECK: DW_TAG_formal_parameter
+  ; CHECK-NEXT:  DW_AT_const_value [DW_FORM_udata]	(0)
+  tail call void @llvm.dbg.value(metadata i64 0, i64 0, metadata !10, metadata !18), !dbg !17
----------------
aprantl wrote:
> probinson wrote:
> > aprantl wrote:
> > > probinson wrote:
> > > > Huh. So we see udata (0) because the zero value is considered as an integer type rather than a float type? And that's supposed to be the entire 128-bit value?
> > > > I wonder if something else weird is going on with _Complex, because on Linux I get DW_AT_location with an expression that describes only one 8-byte piece.
> > > No this is supposed to be the lower 64 bits of the complex 128-bit value.
> > > In order to reproduce this you need to compile for a target that does not have a native 64-bit double data type. (E.g.: -triple=thumbv7-apple-unknown-macho but not thumbv7-apple-ios)
> > How does the consumer know this DW_AT_const_value is only the lower half?  How will it find the upper half?
> > I brought up the Linux behavior only because it also was not describing the upper half, which makes me think there is some deeper problem with describing Complex values.  Sorry, should have made that clear, I am not expecting Linux to trigger the integer thing.
> Good catch, this is due to an unrelated bug. In the IR the value is clearly described by DW_OP_bit_piece(0, 64), however, the bit_piece expression doesn't make it into the final DWARF output.
> 
> Note that describing only the lower half is correct here as the original source is:
>    void f(_Complex double c) { c = 0; }
> If you change that to become
>    void f(_Complex double c) { c = 0 + 1*_Complex_I; }
> you will get two bit_pieces describing real and imaginary parts. However, in this case, our DWARF backend will sub-optimally decide to emit a single-entry location list (totally different code path) because there is more than one DBG_VALUE.
Why is it correct to describe only half the value of the formal parameter?  It is 16 bytes wide and all of it has some location or constant value.
The body of the function assigns an integer literal to a complex variable; the integer literal is promoted to double and used for the real part, and the imaginary part is set to zero.  C11 6.3.1.7 says so.  Therefore there is a known constant value for all the bits of 'c' and the DWARF should describe all of that value.


Repository:
  rL LLVM

http://reviews.llvm.org/D16867