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

[Adrian Prantl via llvm-commits]

aprantl 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
----------------
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.


Repository:
  rL LLVM

http://reviews.llvm.org/D16867