This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Limit the number of values that may be referenced by a dbg.value
ClosedPublic

Authored by StephenTozer on May 26 2021, 5:38 AM.

Details

Summary

Following the merge of D91722, a case has been found where a large number of excessively large DIArgLists were created as a result of salvaging, effectively freezing the compiler. In order to prevent such extreme cases from affecting performance, this patch arbitrarily constrains DIArgLists to containing 16 arguments - any attempt to salvage them further will result in an undef dbg.value.

Although this patch is straightforward and should help deal with the prior performance issue, there is a further step that can be taken that may also help, which would be to reduce the size of undef dbg.values. Currently when we set a dbg.value undef, we just replace the lost value with an UndefValue of equal type, but we could further reduce the size of these dbg.values by removing the contents of the DIArgList and DIExpression, with the exception of any DIExpression operators that still have meaning (such as DW_OP_LLVM_fragment). I can make this into a separate patch, or fold it into this one - any thoughts?

Diff Detail

Event Timeline

StephenTozer created this revision.May 26 2021, 5:38 AM
StephenTozer requested review of this revision.May 26 2021, 5:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 26 2021, 5:38 AM

This makes sense to me.
I remember that when we were experimenting with adding support for salvaging debug info for binary operations dealing with 2 SSA values, we needed to make something like this, since we had encountered some dramatic cases even when building clang itself (I've mentioned this on a patch from this area). Also, I don't have a strong opinion about whether it should be 16 or some other magic value.

jmorse accepted this revision.May 26 2021, 7:15 AM
jmorse added a subscriber: jmorse.

For the record, this LGTM too. Picking a better cut-off point is probably something we can experiment with in the future.

This revision is now accepted and ready to land.May 26 2021, 7:15 AM

Thanks for the change. I tried a few limits on the repro case I mentioned in D91722. It does look like 16 is a sweet spot at least for that case. :) Without forcing a limit, the case runs for 10+ hours..

MaxDebugArgstime
420.5s
820.8s
1620.7s
3222.0s
6431.2s
wenlei accepted this revision.May 26 2021, 8:37 AM

lgtm, thanks.

This revision was landed with ongoing or failed builds.May 26 2021, 9:34 AM
This revision was automatically updated to reflect the committed changes.