[PATCH] D36850: [ThinLTO] Add norecurse function attribute propagation

[Di Mo via Phabricator via llvm-commits]

modimo updated this revision to Diff 351606.
modimo edited the summary of this revision.
modimo added a comment.

Clean up logic around bailing out. Separate out thinLTO statistics from general statistics. Run clang-format.

Gathering some stats on Clang release thinlto self-build:
"function-attrs.NumThinLTONoRecurse": 1542018,

Which isn't unexpected given that the vast majority of functions are norecurse. The counting statistics here are a bit skewed because they are done per summary updated and with operating on weak symbols it may make more sense to count once per ValueInfo.

Notably no other statistics shifted with enabling/disabling propagation and a search through LLVM shows only globalopt `processInternalGlobal` actually uses norecurse ATM. Stats-wise this doesn't fire in either case so it makes sense why codegen doesn't shift.

In that sense, propagating norecurse doesn't seem very valuable. I then tested out nounwind as a better candidate given that currently propagation halts on de-refinable/weak functions when done per-module. Processing in the index, we know every definition and if there's any external definitions meaning propagation can be done confidently through these functions.

Gathering some stats I added (D104161 <https://reviews.llvm.org/D104161>) on a release thinlto -fno-inline build (inlining duplicates landing pads which makes comparisons harder):

thinlto/

  "dwarfehprepare.NumFunctionsProcessed": 630099,
  "dwarfehprepare.NumCleanupLandingPads": 214916,
  "dwarfehprepare.NumNoUnwind": 299357,

thinlto_withpropagation/

  "dwarfehprepare.NumFunctionsProcessed": 629976,
  "dwarfehprepare.NumCleanupLandingPads": 160635,
  "dwarfehprepare.NumNoUnwind": 412014,

Shows a 412014/299357=38% increase in NoUnwind functions and a 160635/214916=25% decrease in the number of cleanup landing pads which is a considerable reduction in EH code.

Measuring performance of Thin Link on Clang self-build I'm seeing a pretty nasty hit of 10s baseline -> 24s with propagation. I'm investigating because as-is this is way too much.


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

https://reviews.llvm.org/D36850

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Transforms/IPO/FunctionAttrs.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/FunctionAttrs.cpp
  llvm/test/ThinLTO/X86/Inputs/functionattr-prop.ll
  llvm/test/ThinLTO/X86/Inputs/linkonce_functionattrs_comdat.ll
  llvm/test/ThinLTO/X86/deadstrip.ll
  llvm/test/ThinLTO/X86/function_entry_count.ll
  llvm/test/ThinLTO/X86/functionattr-prop.ll
  llvm/test/ThinLTO/X86/linkonce_functionattrs_comdat.ll
  llvm/test/ThinLTO/X86/linkonce_resolution_comdat.ll
  llvm/test/ThinLTO/X86/not-internalized.ll
  llvm/test/ThinLTO/X86/weak_externals.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D36850.351606.patch
Type: text/x-patch
Size: 21903 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210612/54d5faee/attachment.bin>