[llvm] [DebugInfo] Set all dbg.value intrinsics to be tail-calls (PR #73661)

Jeremy Morse via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 28 07:44:20 PST 2023


https://github.com/jmorse created https://github.com/llvm/llvm-project/pull/73661

This change has no meaningful effect on the compiler, although it has a functional effect of dbg.value intrinsics being printed differently. The tail-call flag is meaningless for debug-intrinsics and doesn't serve a purpose, it's just extra baggage that dbg.values are built on top of. Some facilities create debug-intrinsics with the flag, others don't. However, the RemoveDIs project to represent debug-info without intrinsics doesn't have a corresponding flag, which can cause spurious test differences.

Specifically: we can convert a dbg.value to a DPValue, run an optimisation pass, then convert the DPValue back to dbg.value form. Right now, we always set the "tail" flag when converting it back. This causes the auto-update-tests script to fail sometimes because in one mode (dbg.value) intrinsics might not have a tail flag, but in the other they do have a tail flag. Consistently picking one or the other in the conversion routine doesn't help, because the rest of LLVM is inconsistent about it anyway.

Thus: whenever we make a dbg.value intrinsic, create it as a tail call, so that we get consistent output behaviours no matter which debug-info mode we're in, DPValue or dbg.value. No tests fail as a result of this patch because the extra 'tail' generated in numerous tests is automatically ignored by FileCheck as being leading-rubbish before the CHECK match.

>From 559d7d0d7ad36c80c33cb7f05cca4bac4adbb04e Mon Sep 17 00:00:00 2001
From: Jeremy Morse <jeremy.morse at sony.com>
Date: Mon, 27 Nov 2023 15:49:34 +0000
Subject: [PATCH] [DebugInfo] Set all dbg.value intrinsics to be tail-calls

This change has no meaningful effect on the compiler, although it has a
functional effect of dbg.value intrinsics being printed differently. The
tail-call flag is meaningless for debug-intrinsics and doesn't serve a
purpose, it's just extra baggage that dbg.values are built on top of. Some
facilities create debug-intrinsics with the flag, others don't. However,
the RemoveDIs project to represent debug-info without intrinsics doesn't
have a corresponding flag, which can cause spurious test differences.

Specifically: we can convert a dbg.value to a DPValue, run an optimisation
pass, then convert the DPValue back to dbg.value form. Right now, we always
set the "tail" flag when converting it back. This causes the
auto-update-tests script to fail sometimes because in one mode (dbg.value)
intrinsics might not have a tail flag, but in the other they do have a tail
flag. Consistently picking one or the other in the conversion routine
doesn't help, because the rest of LLVM is inconsistent about it anyway.

Thus: whenever we make a dbg.value intrinsic, create it as a tail call, so
that we get consistent output behaviours no matter which debug-info mode
we're in, DPValue or dbg.value. No tests fail as a result of this patch
because the extra 'tail' generated in numerous tests is automatically
ignored by FileCheck as being leading-rubbish before the CHECK match.
---
 llvm/lib/IR/DIBuilder.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/llvm/lib/IR/DIBuilder.cpp b/llvm/lib/IR/DIBuilder.cpp
index 0946cf8048f241a..62efaba025344b5 100644
--- a/llvm/lib/IR/DIBuilder.cpp
+++ b/llvm/lib/IR/DIBuilder.cpp
@@ -988,9 +988,11 @@ Instruction *DIBuilder::insertDbgValueIntrinsic(Value *V,
                                                 DIExpression *Expr,
                                                 const DILocation *DL,
                                                 Instruction *InsertBefore) {
-  return insertDbgValueIntrinsic(
+  Instruction *DVI = insertDbgValueIntrinsic(
       V, VarInfo, Expr, DL, InsertBefore ? InsertBefore->getParent() : nullptr,
       InsertBefore);
+  cast<CallInst>(DVI)->setTailCall();
+  return DVI;
 }
 
 Instruction *DIBuilder::insertDbgValueIntrinsic(Value *V,



More information about the llvm-commits mailing list