[PATCH] D136774: [Outliner] Add an option to only enable outlining of patterns above a certain threshold

[Nathan Lanza via Phabricator via llvm-commits]

lanza added a comment.

> Is it impossible to model this in the compiler? Or do we absolutely need a knob for this? In general, I think it'd be best to improve the outliner cost model accuracy wherever possible, just because that is an option at this level of representation. But if it's absolutely necessary to add a heuristic, I'm not totally against it,

This is what I aimed to do initially. The problem I ran into is that coming up with a model against compression is chaotic in the mathematical sense. e.g. the results varied based on the contents of functions in *other libraries* which we obviously don't have visibility into during outlining. We compress our Android native libraries with SuperPack (https://engineering.fb.com/2021/09/13/core-data/superpack/) which concatenates all our libraries and then compresses them asymmetrically. So a change in libraryA changes the criteria for outlining decisions in libraryB.

The situation is possibly the same for iOS apps as well with IPA compression and any usage of dylibs, though I'm not particularly familiar with this domain.

You could definitely come up with a better heuristic to improve the uncompressed size results. e.g. with `-outliner-benefit-threshold=5` I saw over twice the size savings than the default hardcoded `1` yielded. This could be modeled more directly by including, for example, the cost of unwinding info in the outliner cost modeling.

However, that would still be a very poor result if compressed size was important given that it depends

- the compression tool used
- the contents of the other libraries/assets being compressed along side
- the actual valuation your use case has for compressed vs uncompressed code
- etc

Across our different aarch64 apps I still saw different values prevailing as most effective. e.g. `200` for app1, `250` for app2 and `275` for app3 where the only meaningful variation between these apps would be the contents of other libraries. This is definitively not modelable within the compiler. So even with a "correct" uncompressed model we'd still need an override for compressed needs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136774