[DebugInfo] Emit DW_OP_implicit_value for Floating point constants

[SouraVX]

Summary

llvm is missing support for DW_OP_implicit_value operation.
DW_OP_implicit_value op is indispensable for cases such as
optimized out long double variables.

For intro refer: DWARFv5 Spec Pg: 40 2.6.1.1.4 Implicit Location Descriptions

Consider the following example:

int main() {
        long double ld = 3.14;
        printf("dummy\n");
        ld *= ld;
        return 0;
}

when compiled with tunk clang as
clang test.c -g -O1 produces following location description
of variable ld:

DW_AT_location        (0x00000000:
                     [0x0000000000201691, 0x000000000020169b): DW_OP_constu 0xc8f5c28f5c28f800, DW_OP_stack_value, DW_OP_piece 0x8, DW_OP_constu 0x4000, DW_OP_stack_value, DW_OP_bit_piece 0x10 0x40, DW_OP_stack_value)
                  DW_AT_name    ("ld")

Here one may notice that this representation is incorrect(DWARF4
stack could only hold integers(and only up to the size of address)).
Here the variable size itself is 128 bit.
GDB and LLDB confirms this:

(gdb) p ld
$1 = <invalid float value>
(lldb) frame variable ld
(long double) ld = <extracting data from value failed>

GCC represents/uses DW_OP_implicit_value in these sort of situations.
Based on the discussion with Jakub Jelinek regarding GCC's motivation
for using this, I concluded that DW_OP_implicit_value is most appropriate
in this case.

Link: https://gcc.gnu.org/pipermail/gcc/2020-July/233057.html

GDB seems happy after this patch:(LLDB doesn't have support
for DW_OP_implicit_value)

(gdb) p ld
p ld
$1 = 3.14000000000000012434

[dblaikie]

Not sure it's worth committing such a narrow implementation - might be worth a bit of generalization even in this first patch? Or do you have specific/near-term plans to generalize this further (both the addImplicitValue itself, which looks to be very specific to long double right now (but without any assertions, API features, or comments to enforce that restriction) - and in the DwarfDebug.cpp caller, which could presumably be used for all constant values, maybe (not sure if that would be a good thing or not - haven't looked at the alternatives, etc))

@aprantl @probinson will probably want to weigh in on getting support from their debuggers before this is committed, or having this under a flag, etc.

llvm/test/DebugInfo/X86/DW_OP_implicit_value.ll

13–18 ↗

(On Diff #277053)

I'd probably write this as:

long double src();
void f1() {
  long double ld = 3.14;
  ld = src();
}

That should be enough to use the implicit_value to represent the value of 'ld' during the call to src, and to use a location list to do it (since the assignment to 'ld' is shortening the lifetime - using function calls at least I find are clearer opaque clobbers/sinks - rather than the complexity of printf, or wondering whether the use of multiplication is significant, whether this has to be main, has to have an integer return value for some reason, etc.)

[SouraVX]

In D83560#2145768, @dblaikie wrote:

Thanks @dblaikie for your feedback!

Not sure it's worth committing such a narrow implementation - might be worth a bit of generalization even in this first patch?

This operation(as you might have noticed) has limited usage, since DW_OP_stack_value and friends fits in other cases very well. This is specifically made to cater needs(such as in this case) where the variable size is bigger than (size of address). This will cater all the needs in math(HPC) based applications where usage of long double is ubiquitous.

looks to be very specific to long double right now (but without any assertions, API features, or comments to enforce that restriction) - and in the DwarfDebug.cpp caller, which could presumably be used for all constant values, maybe (not sure if that would be a good thing or not - haven't looked at the alternatives, etc))

Yes, that's very specific and you'll notice that it has very strict enforcement requirements isConstrantFP followed by if (AP.getDwarfVersion() >= 4 && RawBytes.getBitWidth() == 80)(making sure we don't mess up existing infra).
For the documentation/comments part, admittedly I didn't put any behavior/requirement specifics in the declaration, However the definition part is fully documented and self-explanatory(IMO). Should we put some brief comments there(declaration part) too ?

@aprantl @probinson will probably want to weigh in on getting support from their debuggers before this is committed, or having this under a flag, etc.

As of now GDB has fairly good support for this. LLDB doesn't have it, I'm not sure how much effort is needed to put this in ?

As a side note and as opportunistic usage of DW_OP_implict_value usage:
I noted following WRT GCC usage of this:
GCC uses DW_OP_implicit_value for long double as well as float double(may be more, these I've verified). clang uses DW_OP_constu followed by DW_OP_stack_value for cases of float double(correctly) and long double (incorrectly as depicted). I assume that since both float and double are within(64 bit) it's okay to represent that using DW_OP_constu and DW_OP_stack_value, but (as you may notice) Spec doesn't say anything whether it should also be used for floating point types
Spec: Pg. 27:

DW_OP_constu
The single operand of the DW_OP_constu operation provides an unsigned LEB128 integer constant.

One more(I would say advantage) for using DW_OP_implicit_value over some DW_OP_stack_value based expression for cases of float and double is that it consumes less space(to be exact 1 byte lesser in case of float and double). (GCC sort of uses an algorithm to choose between these(which representation will take less space))
Consider a simple case:

float f=3.14f;
CLANG based - DW_OP_constu + DW_OP_stack_value expression = 7 bytes
GCC based- DW_OP_implicit_value = 6 bytes
double d = 3.14;
CLANG based - DW_OP_constu + DW_OP_stack_value expression = 11 bytes
GCC based- DW_OP_implicit_value = 10 bytes

These findings also encourage the need for support for DW_OP_implicit_value from LLDB side, otherwise LLDB won't be able to show locations based on these expression.

llvm/test/DebugInfo/X86/DW_OP_implicit_value.ll

13–18 ↗

(On Diff #277053)

Typically the workflow I follow while working on these test cases, is not to solely rely on DWARF but to have a executable as well ready to be loaded to debugger. Otherwise(you may notice, we could have never discovered this, there was an expression but through GDB I came to know that, it' incorrect.)
That's why I putted the test case as it is. If you've concerns WRT this I'm okay with that as well(however I didn't see benefit/drawback in both approaches)
:)

[dblaikie]

In D83560#2145933, @SouraVX wrote:

In D83560#2145768, @dblaikie wrote:

Thanks @dblaikie for your feedback!

Not sure it's worth committing such a narrow implementation - might be worth a bit of generalization even in this first patch?

This operation(as you might have noticed) has limited usage, since DW_OP_stack_value and friends fits in other cases very well. This is specifically made to cater needs(such as in this case) where the variable size is bigger than (size of address). This will cater all the needs in math(HPC) based applications where usage of long double is ubiquitous.

looks to be very specific to long double right now (but without any assertions, API features, or comments to enforce that restriction) - and in the DwarfDebug.cpp caller, which could presumably be used for all constant values, maybe (not sure if that would be a good thing or not - haven't looked at the alternatives, etc))

Yes, that's very specific and you'll notice that it has very strict enforcement requirements isConstrantFP followed by if (AP.getDwarfVersion() >= 4 && RawBytes.getBitWidth() == 80)(making sure we don't mess up existing infra).

The call site criticism I had was: "in the DwarfDebug.cpp caller, which could presumably be used for all constant values, maybe (not sure if that would be a good thing or not - haven't looked at the alternatives, etc))"

For the documentation/comments part, admittedly I didn't put any behavior/requirement specifics in the declaration, However the definition part is fully documented and self-explanatory(IMO). Should we put some brief comments there(declaration part) too ?

The rest of the criticism " looks to be very specific to long double right now (but without any assertions, API features, or comments to enforce that restriction) " applied to the "addImplicitValue" function: Its name is very general, its signature is very general, but the implementation is very specific about a certain width field, etc. Which doesn't seem ideal/quite right. Comments inside the implementation without assertions - with a very general function name seems like it'd be pretty easy to misuse and get unexpected behavior. If the code is going to be so specific then the function name should probably describe that specific behavior and if possible assertions to ensure that's done - perhaps even have it take APFloat. (& I'm not sure whether it's worth choosing between implicit_value and uconst - and just always do implicit_value)

@aprantl @probinson will probably want to weigh in on getting support from their debuggers before this is committed, or having this under a flag, etc.

As of now GDB has fairly good support for this. LLDB doesn't have it, I'm not sure how much effort is needed to put this in ?

Neither am I - and, yeah, if we /just/ did it for 128 bit types, which you've demonstrated are already unusable by lldb - then there would be no harm in making this change sooner. But if we're going to generalize it (& I think the code merits generalization if it weren't for any other constraints) then we'd need to consider how it'd break existing consumers, etc.

[SouraVX]

Sure, I understand the need having specific name(and my mistake of choosing a generic name addImplicitValue for the purpose of this patch). I've noted down and work on your inputs/concerns and revise once @aprantl and @probinson also have a look on it. Thanks again for your inputs :)

Regarding that strange check(80 bit width), at that time I didn't find a way to distinguish b/w float and long double so I did it in a brute force fashion(IEEE representation to distinguish). I'll see if I can do it better.

[SouraVX]

@aprantl @probinson could you folks please provide a quick comment on this as a whole ?
Meanwhile, I also have a patch(locally) which switches to DW_OP_implicit_value for all the floating point constants float, double, long double working fantastic. For correctness checked that executables are debuggable with GDB.

[aprantl]

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

2504–2518

This restriction seems overly strict and also partially wrong.

First off, the condition should be sunk into DwarfExpression. That's were we do the low-level DWARF expression encoding. Maybe we should add a DwarfExpression::addFPConstant(APFloat) function?

An then in the new function, since we cannot represent anything > 64 bit without DW_OP_implicit_value, we should error out if it's not supported, and not emit a broken constant like we did before.

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.h

303

See my comment above. It might be better to have something that takes an APFloat?

[SouraVX]

Addressed review comments by @aprantl, Thanks for this.
Changes:

• Edited the summary to reflect the intention.
• This patch switches to DW_OP_implicit_value for all the floating point constants float, double and long double, for demonstration purposes, considering 1 byte space saving(discussed above).
• Changes are still a bit conservative, in a sense emission of DW_OP_implicit_value is guarded with additional check for debugger tunning.

This will ensure that, we didn't break any existing machinery/consumers.

[SouraVX]

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

2504–2518

An then in the new function, since we cannot represent anything > 64 bit without DW_OP_implicit_value, we should error out if it's not supported, and not emit a broken constant like we did before.

I'll address this in next revision(This one doesn't through error).

[aprantl]

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

234

return;

236

Why would we special-case Float80 instead of just emitting everything that we didn't emit in the above block here unconditionally?

248

should we emit an invalid opcode / and assembler comment / ... to indicate that there was an error?

[SouraVX]

For cases other than those gracefully handled(`float, double, long double) for DW_OP_implicit_value I'm considering a hard error sort of assert/llvm_unreachable or 2nd option could be just bail out early.

And for other consumer targets, still using _stack_value based expression, I'm considering bailing out early for variables > 64 bits instead of incorrectly representing it.

@aprantl do you any suggestions/objection WRT this. Please share!

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

234

Ah, Sorry will take care of that.

236

Initially thought of implementing that way, but due padding issues this cannot be done.
For instance, for long double bit width will be 80 bits(10 bytes) and emit as

emitUnsigned(NumBytes);
for(...)
emitData();

This will ends up in expression of NumBytes(10) in this case, however DW_AT_byte_size for long double type is 16 bytes -- this conflict resulting in following error in GDB

(gdb) p ld
access outside bounds of object referenced via synthetic pointer.

For addressing padding issues and another distant issue(some other Floating point constant with different IEEE representation should not be emitted erronously.)

[aprantl]

For cases other than those gracefully handled(`float, double, long double) for DW_OP_implicit_value I'm considering a hard error sort of assert/llvm_unreachable or 2nd option could be just bail out early.

We should only use llvm_unreachable when it's actually unreachable. If it is possible to create IR input that would cause us to go down this path, we should use some other error reporting mechanism instead. I think I'd be happy with emitting a warning to llvm::dbgs(), or an assembler comment (if that is available here, not sure). We could also emit something like DW_OP_nop or DW_OP_lit0 DW_OP_div, or DW_OP_user_hi. Or we could flag the DwarfExpression object as having an error and enforce the owner to check this before the expression is emitted, but I think that's too much to ask just for this patch :-)

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

236

Thanks for the explanation!

[SouraVX]

Addressed @aprantl review comments. Thanks for this!

[SouraVX]

I think I'd be happy with emitting a warning to llvm::dbgs(), or an assembler comment (if that is available here, not sure).

Here, I've used LLVM_DEBUG so that it won't hurt any thing. This seems Okay to you ?

[aprantl]

Thanks!

[SouraVX]

Temporarily reverted in 9d2da6759b4d05d834371bcaaa8fc3d9b3385b18.
Due to failing/assertion in test case in Sparc Backend.
test/DebugInfo/Sparc/subreg.ll

[SouraVX]

In D83560#2168520, @SouraVX wrote:

Temporarily reverted in 9d2da6759b4d05d834371bcaaa8fc3d9b3385b18.
Due to failing/assertion in test case in Sparc Backend.
test/DebugInfo/Sparc/subreg.ll

Fixed in 59a76d957a2603ee0548293ded170c98e1308c48

[SouraVX]

There was another failure in WebAssembly debug info test case caught by build-bot. That's also fixed with commit id mentioned.
Once the change stabilizes, I plan to do a quick refactoring(wherever applicable WRT this change).

[bjope]

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

234

I'm working on a big-endian target (together with a debugger based on gdb 8.1.0).
I needed to reverse the order here (and in the loop at line 243), to get same result as before.

Does that make sense? Should we care about endianess in DwarfExpression.cpp?

[bjope]

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

234

One thing I noticed is that APFloat::bitcastToAPInt, according to comments in APFloat.cpp, is creating an APInt that is a bit map of the value as it would appear in memory. However, that would only be true if the APInt was stored as one value taking endianess into consideration. When looking at the rawBytes of the resulting APInt after bitcastToAPInt the bytes are in litte-endian order. So a byteSwap is generally needed for big-endian.

[aprantl]

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

234

I don't know what the answer to the question, but I would encourage patches that hide the endianness problems as much as possible. I.e., the DwarfExpression API should have a high-level addConstantFP(const APFloat &Value) call, and DwarfExpression should know about endianness and do the right thing automatically (whatever the right thing is). What would be even better would be to hide endianness in AsmPrinter (instead of emitData1() use a high-level emitEndianCorrectedDataN() call — if such a thing makes sense.

[SouraVX]

It seems to me this is reverted again in 7c182663a857fc87552fa2861c7f94046d55845e . Reverting author @amyk didn't updated here.
I'll see if I can get around the endianness, if that's the only issue ?

[MaskRay]

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

229

The bit ordering is different on SPARC V9, PowerPC, etc. Use write* from https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Support/Endian.h#L415

238

This is x86_fp80 instead of IEEE 754 quadruple-precision floating-point format.

[SouraVX]

It's not just endiannes that is causing trouble to PPC target. Looking at a comment regarding PPC target's long double representation in AsmPrinter.cpp

// PPC's long double has odd notions of endianness compared to how LLVM
// handles it: p[0] goes first for *big* endian on PPC.

This patch does not handle this, I'll see if we can fix this up without too many changes, otherwise I'll file a new review covering all scenarios endianess and this target specific.

EDIT:
@MaskRay, I didn't refreshed the page, saw you comments later. But Thanks :)
Will work on those.

[SouraVX]

Thanks @MaskRay for pointers. Tried similar approach(slightly different, since expression has to be emitted by a separate streamer owned by DebugLocDwarfExpression) to take care of Endianess.

• Temporarily removed long double support since IMHO this might require a deeper surgery. Patch reflects the overall skeleton required for suporting DW_OP_implicit_value.
• @amyk, is it possible for you to try this patch on PPC targets ? So that we won't end up having surprises.

[SouraVX]

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

234

This revision take cares of endiannes.

[amyk]

In D83560#2206363, @SouraVX wrote:

Thanks @MaskRay for pointers. Tried similar approach(slightly different, since expression has to be emitted by a separate streamer owned by DebugLocDwarfExpression) to take care of Endianess.

• Temporarily removed long double support since IMHO this might require a deeper surgery. Patch reflects the overall skeleton required for suporting DW_OP_implicit_value.
• @amyk, is it possible for you to try this patch on PPC targets ? So that we won't end up having surprises.

I have tried this patch on little endian and big endian PowerPC, everything looks OK and I do not see any failures with this patch.

[SouraVX]

Thank @amyk for confirming this. @aprantl and @MaskRay could you guys please share your thoughts on this.

Temporarily removed long double support since IMHO this might require a deeper surgery. Patch reflects the overall skeleton required for suporting DW_OP_implicit_value.

I made this remark, since existing approach leads to manual padding bytes calculation. Exploring a better way to accomplish this.
Some of these big-constants are handled in a more cleaner way in AsmPrinter.cpp static void emitGlobalConstantFP, but I doubt this sort of thing can be re-used. Since expression emission requires it's own streamer(ByteStreamer)and intricacies.

[SouraVX]

@aprantl do you have any concerns WRT this.
Yes commit message and other should reflect the intent, apart from this.

[SouraVX]

Thanks @aprantl for taking out time for reviewing this. I've committed changes in ef8992b9f0189005e0d9e09bd0967301bd7a7cc6 with updated commit message reflecting the intent.
I'll be looking into handling long double in a cleaner way.
Thanks!

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

void DwarfDebug::emitDebugLocValue(const AsmPrinter &AP, const DIBasicType *BT,
   } else if (Value.isTargetIndexLocation()) {
     TargetIndexLocation Loc = Value.getTargetIndexLocation();
     // TODO TargetIndexLocation is a target-independent. Currently only the WebAssembly-specific
     // encoding is supported.
     DwarfExpr.addWasmLocation(Loc.Index, static_cast<uint64_t>(Loc.Offset));
       DwarfExpr.addExpression(std::move(ExprCursor));
       return;
   } else if (Value.isConstantFP()) {
-    APInt RawBytes = Value.getConstantFP()->getValueAPF().bitcastToAPInt();
-    DwarfExpr.addUnsignedConstant(RawBytes);
+    if (AP.getDwarfVersion() >= 4 && AP.getDwarfDebug()->tuneForGDB()) {
+      DwarfExpr.addConstantFP(Value.getConstantFP()->getValueAPF(), AP);
+      return;
+    } else if (Value.getConstantFP()
+                   ->getValueAPF()
+                   .bitcastToAPInt()
+                   .getBitWidth() <= 64 /*bits*/)
+      DwarfExpr.addUnsignedConstant(
+          Value.getConstantFP()->getValueAPF().bitcastToAPInt());
+    else
+      LLVM_DEBUG(
+          dbgs()
+          << "Skipped DwarfExpression creation for ConstantFP of size"
+          << Value.getConstantFP()->getValueAPF().bitcastToAPInt().getBitWidth()
+          << " bits\n");
   }
   DwarfExpr.addExpression(std::move(ExprCursor));
 }
 
 void DebugLocEntry::finalize(const AsmPrinter &AP,
                              DebugLocStream::ListBuilder &List,
                              const DIBasicType *BT,
                              DwarfCompileUnit &TheCU) {

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.h

public:
   void addSignedConstant(int64_t Value);
 
   /// Emit an unsigned constant.
   void addUnsignedConstant(uint64_t Value);
 
   /// Emit an unsigned constant.
   void addUnsignedConstant(const APInt &Value);
 
+  /// Emit an floating point constant.
+  void addConstantFP(const APFloat &Value, const AsmPrinter &AP);
+
   /// Lock this down to become a memory location description.
   void setMemoryLocationKind() {
     assert(isUnknownLocation());
     LocationKind = Memory;
   }
 
   /// Lock this down to become an entry value location.
   void setEntryValueFlags(const MachineLocation &Loc);

llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp

 
 #include "DwarfExpression.h"
 #include "DwarfCompileUnit.h"
 #include "llvm/ADT/APInt.h"
 #include "llvm/ADT/SmallBitVector.h"
 #include "llvm/BinaryFormat/Dwarf.h"
 #include "llvm/CodeGen/Register.h"
 #include "llvm/CodeGen/TargetRegisterInfo.h"
+#include "llvm/IR/DataLayout.h"
 #include "llvm/IR/DebugInfoMetadata.h"
 #include "llvm/Support/ErrorHandling.h"
 #include <algorithm>
 #include <cassert>
 #include <cstdint>
 
 using namespace llvm;
 
+#define DEBUG_TYPE "dwarfdebug"
+
 void DwarfExpression::emitConstu(uint64_t Value) {
   if (Value < 32)
     emitOp(dwarf::DW_OP_lit0 + Value);
   else if (Value == std::numeric_limits<uint64_t>::max()) {
     // Only do this for 64-bit values as the DWARF expression stack uses
     // target-address-size values.
     emitOp(dwarf::DW_OP_lit0);
     emitOp(dwarf::DW_OP_not);
while (Offset < Size) {
     if (Offset == 0 && Size <= 64)
       break;
     addStackValue();
     addOpPiece(std::min(Size - Offset, 64u), Offset);
     Offset += 64;
   }
 }
 
+void DwarfExpression::addConstantFP(const APFloat &APF, const AsmPrinter &AP) {
+  assert(isImplicitLocation() || isUnknownLocation());
+  APInt API = APF.bitcastToAPInt();
+  int NumBytes = API.getBitWidth() / 8;
+  if (NumBytes == 4 /*float*/ || NumBytes == 8 /*double*/) {
+    // FIXME: Add support for `long double`.
+    emitOp(dwarf::DW_OP_implicit_value);
+    emitUnsigned(NumBytes /*Size of the block in bytes*/);
+
+    const uint64_t *Value = API.getRawData();
+    const bool IsLittleEndian = AP.getDataLayout().isLittleEndian();
+    uint64_t Swapped = support::endian::byte_swap(
+        *Value, IsLittleEndian ? support::little : support::big);
+
+    const char *SwappedBytes = reinterpret_cast<const char *>(&Swapped);
+    for (int i = 0; i < NumBytes; ++i)
+      emitData1(SwappedBytes[i]);
+
+    return;
+  }
+  LLVM_DEBUG(
+      dbgs() << "Skipped DW_OP_implicit_value creation for ConstantFP of size: "
+             << API.getBitWidth() << " bits\n");
+}
+
 bool DwarfExpression::addMachineRegExpression(const TargetRegisterInfo &TRI,
                                               DIExpressionCursor &ExprCursor,
                                               unsigned MachineReg,
                                               unsigned FragmentOffsetInBits) {
   auto Fragment = ExprCursor.getFragmentInfo();
   if (!addMachineReg(TRI, MachineReg, Fragment ? Fragment->SizeInBits : ~1U)) {
     LocationKind = Unknown;
     return false;

llvm/test/DebugInfo/X86/float_const_loclist.ll

 ;
 ; SANITY: CALL{{.*}} @barrier
 ; SANITY: DBG_VALUE x86_fp80 0xK4000C8F5C28F5C28F800
 ; SANITY: DBG_VALUE float 0x40091EB860000000
 ; SANITY: TAILJMP{{.*}} @barrier
 ;
 ; CHECK: .debug_info contents:
 ; CHECK: DW_TAG_variable
-; CHECK-NEXT:  DW_AT_location {{.*}} (
-; CHECK-NEXT:    [0x[[START:.*]], 0x[[END:.*]]): DW_OP_constu 0xc8f5c28f5c28f800, DW_OP_piece 0x8, DW_OP_constu 0x4000, DW_OP_bit_piece 0x10 0x40)
 ; CHECK-NEXT:  DW_AT_name {{.*}}"ld"
 ; CHECK: DW_TAG_variable
 ; CHECK-NEXT:  DW_AT_location {{.*}} (
-; CHECK-NEXT:    [0x[[START]], 0x[[END]]): DW_OP_constu 0x4048f5c3)
+; CHECK-NEXT:    [0x{{.*}}, 0x{{.*}}): DW_OP_constu 0x4048f5c3)
 ; CHECK-NEXT:  DW_AT_name {{.*}}"f"
 
 source_filename = "test.c"
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.11.0"
 
 ; Function Attrs: nounwind ssp uwtable
 define void @foo() #0 !dbg !4 {

llvm/test/DebugInfo/X86/implicit_value-double.ll

+;; This test checks for emission of DW_OP_implicit_value operation
+;; for double type.
+
+; RUN: llc -debugger-tune=gdb -filetype=obj %s -o - | llvm-dwarfdump - | FileCheck %s
+
+; CHECK: .debug_info contents:
+; CHECK: DW_TAG_variable
+; CHECK-NEXT:  DW_AT_location        ({{.*}}
+; CHECK-NEXT:                     [{{.*}}): DW_OP_implicit_value 0x8 0x1f 0x85 0xeb 0x51 0xb8 0x1e 0x09 0x40)
+; CHECK-NEXT:  DW_AT_name    ("d")
+
+;; Generated from: clang -ggdb -O1
+;;int main() {
+;;        double d = 3.14;
+;;        printf("dummy\n");
+;;        d *= d;
+;;        return 0;
+;;}
+
+; ModuleID = 'implicit_value-double.c'
+source_filename = "implicit_value-double.c"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+@str = private unnamed_addr constant [6 x i8] c"dummy\00", align 1
+
+; Function Attrs: nofree nounwind uwtable
+define dso_local i32 @main() local_unnamed_addr #0 !dbg !7 {
+entry:
+  call void @llvm.dbg.value(metadata double 3.140000e+00, metadata !12, metadata !DIExpression()), !dbg !14
+  %puts = call i32 @puts(i8* nonnull dereferenceable(1) getelementptr inbounds ([6 x i8], [6 x i8]* @str, i64 0, i64 0)), !dbg !15
+  call void @llvm.dbg.value(metadata double undef, metadata !12, metadata !DIExpression()), !dbg !14
+  ret i32 0, !dbg !16
+}
+
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+; Function Attrs: nofree nounwind
+declare i32 @puts(i8* nocapture readonly) local_unnamed_addr #2
+
+attributes #0 = { nofree nounwind uwtable }
+attributes #1 = { nounwind readnone speculatable willreturn }
+attributes #2 = { nofree nounwind }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 11.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "implicit_value-double.c", directory: "/home/")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{!"clang version 11.0.0"}
+!7 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags: DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !11)
+!8 = !DISubroutineType(types: !9)
+!9 = !{!10}
+!10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!11 = !{!12}
+!12 = !DILocalVariable(name: "d", scope: !7, file: !1, line: 2, type: !13)
+!13 = !DIBasicType(name: "double", size: 64, encoding: DW_ATE_float)
+!14 = !DILocation(line: 0, scope: !7)
+!15 = !DILocation(line: 3, column: 2, scope: !7)
+!16 = !DILocation(line: 5, column: 2, scope: !7)

llvm/test/DebugInfo/X86/implicit_value-float.ll

+;; This test checks for emission of DW_OP_implicit_value operation
+;; for float type.
+
+; RUN: llc -debugger-tune=gdb -filetype=obj %s -o - | llvm-dwarfdump - | FileCheck %s
+
+; CHECK: .debug_info contents:
+; CHECK: DW_TAG_variable
+; CHECK-NEXT:  DW_AT_location        ({{.*}}
+; CHECK-NEXT:                     [{{.*}}): DW_OP_implicit_value 0x4 0xc3 0xf5 0x48 0x40)
+; CHECK-NEXT:  DW_AT_name    ("f")
+
+;; Generated from: clang -ggdb -O1
+;;int main() {
+;;        float f = 3.14f;
+;;        printf("dummy\n");
+;;        f *= f;
+;;        return 0;
+;;}
+; ModuleID = 'implicit_value-float.c'
+source_filename = "implicit_value-float.c"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+@str = private unnamed_addr constant [6 x i8] c"dummy\00", align 1
+
+; Function Attrs: nofree nounwind uwtable
+define dso_local i32 @main() local_unnamed_addr #0 !dbg !7 {
+entry:
+  call void @llvm.dbg.value(metadata float 0x40091EB860000000, metadata !12, metadata !DIExpression()), !dbg !14
+  %puts = call i32 @puts(i8* nonnull dereferenceable(1) getelementptr inbounds ([6 x i8], [6 x i8]* @str, i64 0, i64 0)), !dbg !15
+  call void @llvm.dbg.value(metadata float undef, metadata !12, metadata !DIExpression()), !dbg !14
+  ret i32 0, !dbg !16
+}
+
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+; Function Attrs: nofree nounwind
+declare i32 @puts(i8* nocapture readonly) local_unnamed_addr #2
+
+attributes #0 = { nofree nounwind uwtable }
+attributes #1 = { nounwind readnone speculatable willreturn }
+attributes #2 = { nofree nounwind }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 11.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "implicit_value-float.c", directory: "/home/")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{!"clang version 11.0.0"}
+!7 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags: DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !11)
+!8 = !DISubroutineType(types: !9)
+!9 = !{!10}
+!10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!11 = !{!12}
+!12 = !DILocalVariable(name: "f", scope: !7, file: !1, line: 2, type: !13)
+!13 = !DIBasicType(name: "float", size: 32, encoding: DW_ATE_float)
+!14 = !DILocation(line: 0, scope: !7)
+!15 = !DILocation(line: 3, column: 2, scope: !7)
+!16 = !DILocation(line: 5, column: 2, scope: !7)