[PATCH] D133925: [DebugInfo] Fix: Variables that have no non-empty values being emitted when they have a DBG_VALUE_LIST

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 10 11:10:18 PST 2023


dblaikie added a comment.

In D133925#4039071 <https://reviews.llvm.org/D133925#4039071>, @StephenTozer wrote:

> In D133925#4037971 <https://reviews.llvm.org/D133925#4037971>, @dblaikie wrote:
>
>> Hmm - shouldn't we still see `localh` emitted, but without a `DW_AT_location` - dropping the variable entirely seems incorrect? I guess just for this test case that happens because the variable isn't listed in the `DISubprogram`'s `variables` list?
>
> I recall there was some discussion about this a while ago but don't recall the conclusions - regardless of what should ideally be done, this patch doesn't change the way we handle always-undef variables in itself, it only prevents variadic debug values from behaving differently to normal debug values.
>
>> Though internally at Google we're seeing an increase in the `llvm-dwarfdump --statistics` result for `#params with binary locations/#params` and `#local vars with binary locations/#local vars` - which suggests maybe this change is having the effect of dropping some variables entirely, leading to an apparent increase in these statistics?
>
> It's possible that this patch is causing that, but I think it's unlikely - the only change this patch makes is to make `DBG_VALUE_LIST`s behave the same way as normal `DBG_VALUE`s w.r.t. being dropped. DBG_VALUE_LIST instructions do not usually make up a high % of locations, so it seems unlikely you'd see a large change, and more importantly I think they would rarely be used for parameters since they are only produced by attempting to salvage debug info from dead instructions, which isn't as likely to happen to parameters - they could still be assigned values that get salvaged into DBG_VALUE_LISTs later, but at that point we'd be looking at a fraction of a fraction of parameters being affected.

I'll see if I can come up with a reproducer. Do you have an example of this from clang, rather than from handcrafted IR?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133925



More information about the llvm-commits mailing list