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

Tue Apr 27 12:14:41 PDT 2021

dblaikie added subscribers: rupprecht, Carrot.
dblaikie added a comment.

In D101373#2720558 <https://reviews.llvm.org/D101373#2720558>, @StephenTozer wrote:

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

Hmm - not sure I follow. The LLVM IR for the reproduce @rupprecht gave seems to be about half that (~460 lines) - in any case, one workaround could be to include a test-only flag for the limit and set the limit artificially low for testing.

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

Yeah, fair

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

Sorry, I should clarify: I mean the actual assembly generated for this seems inefficient - even when building without debug info. It uses a whole lot of stack space, when it could use one register and add to it between each call. (@Carrot - is this of any interest to you, maybe? Check the codegen for https://reviews.llvm.org/D91722#2718316 - each call has its value placed on a separate stack slot, then after all the calls each stack value is added together/onto ebx - rather than adding onto a callee save register after each call, perhaps? (I think that's what GCC does))
Though fixing the codegen of course wouldn't guarantee the debug info never grows this large - so fixing the growth is important even if someone changes the codegen to be less problematic in this specific case.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101373