[PATCH] D130954: [DeadArgElim] Clear state before returning (NFC).

[Michele Scandale via Phabricator via llvm-commits]

michele.scandale added a comment.

In D130954#3693854 <https://reviews.llvm.org/D130954#3693854>, @aeubanks wrote:

> if you can measure that doing this has measurable compile time improvements for your use case then I think this is reasonable, but it'd be good to measure that this actually helps before proceeding

I did a quick comparison on three class of inputs (trivial(*), small, large) for a custom pipeline based on the default O2 <https://reviews.llvm.org/owners/package/2/> one.
I've measured the time need to build the pass manager at every input and compared it with the time needed to run the pass manager on each of the input.

On the class of trivial inputs rebuilding the (new) pass manager for every module takes ~8.4% of the combined time (with the legacy pass manager it is 66.4%).
On the class of small inputs rebuilding the (new) pass manager for every module takes ~1.4% of the combined time (with the legacy pass manager it is 27.4%).
On the class of large inputs rebuilding the (new) pass manager for every module takes ~0.2% of the combined time (with the legacy pass manager it is 3.7%).

In the overall comparison between legacy vs. new, the new pass manager (even rebuilding it for every input) lead to better overall running time in all the three classes of inputs.

Based on these preliminary results, I can drop the requirement of reusing pass managers when adopting the new pass manager infrastructure.

(*) The class of trivial inputs  (although quite unrealistic) represents the worst case for this experiment -- basically there is nothing to optimize, and it roughly measures the pass manager infrastructure overhead.

In D130954#3693737 <https://reviews.llvm.org/D130954#3693737>, @aeubanks wrote:

> Supporting this adds complexity, even if only a little.
> Is the overhead of creating multiple pass managers measurable with your use case?

I understand that to allow the reuse of pass managers each pass must ensure that no state maintained between `run` invocations, which is very subtle issue, not easy to reproduce, and debug, and it requires pass authors to be more careful. This was true also with the legacy pass manager, and in the past bugs of the same nature have been fixed (e.g. what has lead to the `run-twice` option in `opt`).

If for the new pass manager there is no expectation to support reusing the same pass manager instance for processing different modules, then I think it would be better to have a note about this in the pass manager documentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130954