This is an archive of the discontinued LLVM Phabricator instance.

[LiveDebugValues] Add cutoffs to avoid pathological behavior
ClosedPublic

Authored by vsk on May 27 2020, 2:10 PM.

Details

Summary

We received a report of LiveDebugValues consuming 25GB+ of RAM when
compiling code generated by Unity's IL2CPP scripting backend.

There's an initial 5GB spike due to repeatedly copying cached lists of
MachineBasicBlocks within the UserValueScopes members of VarLocs.

But the larger scaling issue arises due to the fact that prior to range
extension, there are 81K basic blocks and 156K DBG_VALUEs: given enough
memory, LiveDebugValues would insert 101 million MIs (I counted this by
incrementing a counter inside of VarLoc::BuildDbgValue).

It seems like LiveDebugValues would have to be rearchitected to support
this kind of input (we'd need some new represntation for DBG_VALUEs that
get inserted into ~every block via flushPendingLocs). OTOH, large globs
of auto-generated code are typically not debugged interactively.

So: add cutoffs to disable range extension when the input is too big. I
chose the cutoffs experimentally, erring on the conservative side. When
compiling a large collection of Apple software, range extension never
got disabled.

rdar://63418929

Diff Detail

Event Timeline

vsk created this revision.May 27 2020, 2:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 27 2020, 2:10 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
vsk added a subscriber: debug-info.May 27 2020, 2:18 PM

I think this is reasonable. I think the implementation of the Value Tracking within GCC uses a magic value where it applies a similar cutoff if the number of BBs is higher than that.

jmorse accepted this revision.May 28 2020, 9:46 AM

LGTM, definitely better to bail out than to try something impossible.

llvm/lib/CodeGen/LiveDebugValues.cpp
1769

Iterating over all instructions again is probably unfortunate for performance -- it could be counted on line 1744 of this patch?

On the other hand, given the exceptional circumstances that this will trigger in, that's not really a concern.

This revision is now accepted and ready to land.May 28 2020, 9:46 AM
aprantl accepted this revision.May 28 2020, 10:39 AM
vsk marked an inline comment as done.May 28 2020, 1:43 PM

Thanks for the reviews!

llvm/lib/CodeGen/LiveDebugValues.cpp
1769

It seems a bit cleaner to separate the concerns. For inputs where the extra scan would be a performance issue, the pass is likely to bail out anyway.

This revision was automatically updated to reflect the committed changes.