[llvm-dev] BoF: Debug info for optimized code.

Tue Nov 1 14:28:16 PDT 2016

I would love to be able to attend this BoF, but unfortunately I cannot.  I would however like to add a couple of things for consideration during this discussion.

Our custom processor is a VLIW processor, and I think that there is a growing trend in CPU design toward VLIW as transistor count increases, but clock speed does not.  When we compile at '-O0' we do not use more than one functional-unit at a time (except for the predication unit plus one other because we have to).  This means that each "instruction" corresponds to a particular line of code, and an assembly '.loc' directive can be emitted for that instruction which produces a reasonably straight-forward correspondence between the instruction and the source code location.

Optimisation for scalar processors introduces all sorts of fun - code-motion, code-duplication, code-elimination, you name it - but even so, an instruction generally corresponds to some line of code in the source even if it is not obvious to the person debugging their code why the line-tracking jumps around all the time.

But VLIW optimisation introduces a new twist in that each of the functional-units can correspond to different lines of code, and this is really very hard to understand in optimised code when debugging.  The more functional units the VLIW architecture supports, the more difficult this becomes.  And to complicate this further, predication units can control some functional-units and not others, so a single instruction may contain elements which are conditional and other elements which are not, and of course corresponding to several different lines of code.

I do not even pretend to know much about Dwarf and the representation of debug information, but it does appear that there is little or no support for the idea that a single "instruction" can correspond to multiple diverse lines in the source file.  It would be useful for an assembly '.loc' directive to take a list of source locations, and for the debug meta-data to represent this one-to-many mapping ('.debug_{[a]ranges|lines}' etc.).  At the moment we are limited to picking one of the several possible locations, and hoping that it is helpful to the programmer when debugging their optimised programs.

Perhaps this is simply my misunderstanding of the degree of meta-data support in Dwarf, but I don't see any obvious way of representing the one-to-many mapping in LLVM for bundles, or the selective predication of the elements in the bundle.  This kind of bundling happens very late in the MI level, and by then the DebugLoc abstractions are getting quite difficult.  For instance, how do I tell LLVM that some of the instructions in a bundle that contain a predicate are predicated by that predicate, and while instructions are always active?  And how does this pass on to the debug meta-data?  The Dwarf support in LLVM is (thankfully) largely independent of the target, but it still needs to have support for these abstractions and use-cases.

Another area that is really very painful for programmers, whether VLIW or scalar, is C++ templates.  This is an enormously complex area to debug, in particular because the optimised program usually involves extensive use of inlining and multiple tiers of template specialisations.  Even reasoning about the specialisation, whether at '-O0' or fully optimised is incredibly hard.

I don't yet have out-of-tree contributions to make, because I have to admit I struggle with this too, but I have some ideas which I would like to promote in the future once I have ironed out the details.  But it would be good to have the topic of VLIW and C++ templates added to the hot-topics for the BoF.

Thanks and I am looking forward to reading about the outcome from this BoF,

	MartinO

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Adrian Prantl via llvm-dev
Sent: 30 October 2016 15:54
To: LLVM Dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] BoF: Debug info for optimized code.

Debugging optimized code is a topic that generated a lot of interest at previous dev meetings, but often fell somewhat short since we've all been very busy with improving the compile-time performance impact of debug info. This year we'd like to make up for this by inviting to a dedicated session on just "-O" and "-g"!

We will be giving a quick introduction to summarize the current state of debug info handling in LLVM and highlight some of the biggest problem areas.  To get a productive discussion going, here are some points we'd like to invite you to think about ahead of time:

* What are the major pain points that you or your customers
  experience? What works — what doesn't?

* Do you have out-of-tree patches that improve the optimized
  debugging experience? What are your experiences with it and
  what are the challenges in upstreaming them?

* We would really like to start tracking debug info quality the
  same way we track code size and performance numbers. What are
  useful metrics for your use-case?

See you all at the dev meeting!

Adrian Prantl
Fred Riss
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev