[PATCH] D101373: [DebugInfo] Drop DBG_VALUE_LISTs with an excessive number of debug operands

Stephen Tozer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 27 12:06:53 PDT 2021


StephenTozer added a comment.

In D101373#2720352 <https://reviews.llvm.org/D101373#2720352>, @dblaikie wrote:

> This presumably needs a test case.

Indeed, I'm working on right now - it just needs to be reduced significantly, any "organic" reproducer for this results in an excessively large test file (~1000 lines with the simplest .cpp reproducer).

> But also: The DWARF we're generating here is pretty heinous - is the intent that this is a short term fix, but some attempt to reign in these /massive/ expressions is on your/someone's TODO list?

I think right now it's a bit of an open question as to what we do with these. It does leave us in slightly unfamiliar territory w.r.t debug info; usually our concern is just recovering as much debug info as we can, and we usually only intentionally remove it either when we need to due to an optimization, or when some debug info is redundant/unused. I think we can do some testing to determine what should be considered the limit (if any), and/or use a heuristic to find debug information that can be dropped without causing much impact to an end-user.

> Hmm, I guess maybe the DWARF expression size isn't the fault of the DWARF location generation itself, instead maybe it's a function of some weird/bad codegen? We're spilling all these values to the stack even at -O3? 248 byte stack frame for this function?

While this is a weird case, it seems to be legitimate as far as I can tell - we have a variable with at least one use, and a value that is the sum of 64 (or more) function calls. I may be missing something (I'm not a CodeGen expert by any means), but it seems as though the `DBG_VALUE_LIST` itself is correct - we've 64 different values and our variable is known to be the sum of all of them. It's possible that there is a failure to efficiently optimize here, as we have the result of every single function call either in a register or on the stack and then sum them, rather than reusing a single register/stack slot for each call and calculating a rolling sum, but the code is still correct and LiveDebugVariables shouldn't crash upon encountering it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101373/new/

https://reviews.llvm.org/D101373



More information about the llvm-commits mailing list