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

Michele Scandale via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 2 09:17:39 PDT 2022


michele.scandale added a comment.

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

> In D130954#3693701 <https://reviews.llvm.org/D130954#3693701>, @michele.scandale wrote:
>
>> In D130954#3693243 <https://reviews.llvm.org/D130954#3693243>, @nikic wrote:
>>
>>> Is there an RFC (or other context) for this patch series? It's not entirely obvious to me why we want to go out of the way to allow multiple run() calls.
>>
>> I would think that a pass manager instance can be reused for processing different modules (that's why there might be multiple calls to `run`). This is something that so far has been working overall fine with the legacy pass manager. Is there something fundamentally different in the new pass manager infrastructure for which the same pass manager cannot be used for more than one module?
>
> Supporting this adds complexity, even if only a little.
> Is the overhead of creating multiple pass managers measurable with your use case?

With the legacy pass manager one of the concern was the extra latency caused by the construction of a pass manager for every input being processed, in particular for small input modules. As mentioned in https://reviews.llvm.org/D130952#3693697, I'm trying to port the existing logic the new pass manager infrastructure, and while doing so I've found a bunch of issues.

If this is a use case not explicitly supported/recommended, then I will try to see if with the new pass manager infrastructure it is acceptable to rebuild the optimization pipelines every time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130954



More information about the llvm-commits mailing list