This is an archive of the discontinued LLVM Phabricator instance.

[NFC][InlineAdvisor] Inform advisor when the module is invalidated
ClosedPublic

Authored by mtrofin on Nov 10 2021, 8:59 PM.

Details

Summary

This avoids unnecessary re-calculation of module-wide features in the
MLInlineAdvisor. In cases where function passes don't invalidate
functions (and, thus, don't invalidate the module), but we re-process a
CGSCC, we currently refreshed module features unnecessarily. The
overhead of fetching cached results (albeit they weren't themselves
invalidated) was noticeable in certain modules' compilations.

We don't want to just invalidate the advisor object, though, via the
analysis manager, because we'd then need to re-create expensive state
(like the model evaluator in the ML 'development' mode).

Diff Detail

Event Timeline

mtrofin created this revision.Nov 10 2021, 8:59 PM
mtrofin requested review of this revision.Nov 10 2021, 8:59 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 10 2021, 8:59 PM
phosek accepted this revision.Nov 10 2021, 11:13 PM

LGTM

This revision is now accepted and ready to land.Nov 10 2021, 11:13 PM

It looks like the expensive part is recalculating FunctionPropertiesAnalysis in getLocalCalls(). Since you're only using DirectCallsToDefinedFunctions, could you implement that yourself rather than relying on the potentially expensive FunctionPropertiesAnalysis? For example, it looks like it needs to construct all the loops in the function which could be expensive.
Counting by hand the number of direct calls should be quick and unnoticeable in terms of compile time.

It looks like the expensive part is recalculating FunctionPropertiesAnalysis in getLocalCalls(). Since you're only using DirectCallsToDefinedFunctions, could you implement that yourself rather than relying on the potentially expensive FunctionPropertiesAnalysis? For example, it looks like it needs to construct all the loops in the function which could be expensive.
Counting by hand the number of direct calls should be quick and unnoticeable in terms of compile time.

You mean avoid using the analysis infra altogether there? I could, but:

  • I'd still need to compute stuff unnecessarily in this scenario
  • we may later want to rely on some other analysis results, so we'd be back to this place.

are you actually seeing compile time improvements with this patch?

if nothing has been invalidated, then FunctionPropertiesAnalysis is still cached, and the recalculation would be negligible since we're just iterating through each function in the module and getting a cached int for each one and summing them together, which is basically free

are you actually seeing compile time improvements with this patch?

yes. significant

if nothing has been invalidated, then FunctionPropertiesAnalysis is still cached, and the recalculation would be negligible since we're just iterating through each function in the module and getting a cached int for each one and summing them together, which is basically free

that cache retrieval is what's not free, when the scale is large.

you could create a new module analysis which computes NodeCount/EdgeCount via FunctionPropertiesAnalysis. that's the most NPM-y way of doing this. then you'd MAM.getResult<MyModulePropertiesAnalysis>(M) which would only recalculate if it's been invalidated

but if this is to unblock something you can land this first

mtrofin added a comment.EditedNov 11 2021, 10:17 AM

you could create a new module analysis which computes NodeCount/EdgeCount via FunctionPropertiesAnalysis. that's the most NPM-y way of doing this. then you'd MAM.getResult<MyModulePropertiesAnalysis>(M) which would only recalculate if it's been invalidated

but if this is to unblock something you can land this first

ack - thanks; yes, leme unblock Fuchsia with this, then I'll try the cleaner method.

This revision was landed with ongoing or failed builds.Nov 11 2021, 10:23 AM
This revision was automatically updated to reflect the committed changes.