[PATCH] D110332: [DebugInfo] Limit the size of DIExpressions that we will salvage up to

Sanjay Patel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 15 08:07:00 PDT 2021


spatel added a comment.

In D110332#3066881 <https://reviews.llvm.org/D110332#3066881>, @StephenTozer wrote:

> In D110332#3018090 <https://reviews.llvm.org/D110332#3018090>, @spatel wrote:
>
>> Thanks for working on this! I don't know anything about debug info/salvaging implementation, so I can't review the patch, but I hope someone else will have a look.
>>
>> Could this reduce compile time in this config:
>> https://llvm-compile-time-tracker.com/?config=NewPM-ReleaseLTO-g&stat=instructions ?
>>
>> If so, it would be good to know that number before committing - maybe tune the MaxExpressionSize setting for most benefit based on those benchmarks.
>
> I've tested a few different versions on the compile time tracker, but I'm afraid I can't see any measurable difference - probably because most programs will never hit this limit to begin with, so it makes little difference performance-wise where we draw the line. With respect to the reported broken file, the most significant performance impact of lengthening the allowed expressions is increasing the size of the intermediate file (so memory usage, and disk space if the intermediate file is saved). In terms of performance, there doesn't seem to be a huge difference, but 128 seems a good medium to draw it at. We could go down to 64, since most programs will never hit that with a legitimate expression anyway, but 128 is already low enough to make the pathological cases manageable, so we have enough leeway to support potentially very large expressions.

Sounds good. Thanks for checking.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110332



More information about the llvm-commits mailing list