[PATCH] D116821: [DebugInfo][InstrRef] Move instr-ref controlling flag out of TargetOptions

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

Hi @alexfh , first many thanks for coming back with details and a reproducer!,

> The most problematic are User time (seconds): 190.92 -> 255.60 (+34%) and Maximum resident set size (kbytes): 4926000 -> 27272308 (5.5x).

Oooooff :/,

> As for the nature of the code, it's a large generated file (preprocessed size ~22MB) with a few kinds of boilerplate (e.g. a method with a ton of v->push_back({some, constant}); calls and other stuff). I can try to find out which of them is responsible for most of the increase.

As ever, generated code can easily stimulates limitations, and in this case it's really exciting: the culprit is ASAN having thousands of live pointers to wherever it is asan stores things. They all get spilt to the stack: and because my working assumption when writing this code was that LLVM would usually seek to minimise the working set size for obvious reasons, InstrRefBasedLDV tries to track all the spilt values in every block, which in this case is thousands of slots. That leads to the ballooning memory consumption, which won't be fixed by the other improvements I've made. The cherry on the cake is that, because asan pointers don't have any variables associated with them, there's zero improvement in debug experience from instr-ref on this sample.

VarLocBasedLDV does just fine because it only tracks locations after they're assigned to a variable; instr-ref tracks everything to increase the number of locations that are known to contain a value, hence this explosion.

An easy way out would be to set a hard limit on the number of spill slots being tracked, on the (to me) fairly reasonable principle of "If your working set is over (say) 1000 Values, you probably autogenerated this code and probably won't be debugging it by hand", much like existing cut-offs in LiveDebugValues. I instinctively don't want to add arbitrary limits though.

I'll give it some more thought over the weekend. The assumption about the working set being small is pretty heavily baked into what I've been writing though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116821