[PATCH] D113520: [SROA] Spill alloca's around non-capturing escapes via calls to allow alloca partitioning/promotion

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri updated this revision to Diff 387047.
lebedev.ri added a comment.

Introduce profitability heuristic so that the compiler doesn't take out
the whole machine while trying to build e.g. vanilla llvm test-suite :)

The current rule-of-thumb is:
For an escaped alloca to be worthy of promotion,
it must be used by loads/stores in this function (i.e., no point in promoting https://godbolt.org/z/c51Yavv9P)
and either have a small total size (32 bytes currently,
very much a guess), or most of the bytes of the alloca
(>=80%, also a guess) must be loaded/stored within this function (i.e. not much point in promoting https://godbolt.org/z/7KToqzb6z)

This results in these numbers:
https://llvm-compile-time-tracker.com/compare.php?from=8d35c054e31e5a2bee082f7a587a660eeb24bf99&to=c7226d770b1ffa1117f724dd25de7fa2881eed18&stat=instructions
... and i'm not sure what is going on with `tramp3d-v4`'s `NewPM-ReleaseThinLTO` build,
i can't reproduce the horrible slowdown locally (do i need a production debug/assert-less build?).

This transform does not do anything crazy on that code,
the alloca's that happen to be promoted are very tiny (<=32b),
and we introduce only a single spill/reload per each,
so this isn't something i see as preventable with profitability checks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113520

Files:
  llvm/lib/Transforms/Scalar/SROA.cpp
  llvm/test/Transforms/PhaseOrdering/lifetime-sanitizer.ll
  llvm/test/Transforms/SROA/non-capturing-call.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D113520.387047.patch
Type: text/x-patch
Size: 67937 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211113/77ce972b/attachment.bin>