[PATCH] D72404: [ThinLTO/FullLTO] Support Os and Oz

Mehdi AMINI via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Feb 9 11:32:18 PST 2022

mehdi_amini added a comment.

In D72404#3307623 <https://reviews.llvm.org/D72404#3307623>, @aykevl wrote:

> So, should all passes just look at the `optsize` and `minsize` attributes instead of the `SizeLevel`? In other words, should `PassManagerBuilder.SizeLevel` be removed and should passes only look at function attributes instead of `SizeLevel`? Because at the moment, it's a weird mix of both. IMHO size level should either all go via function attributes or via a flag, not something in between as it is now.

I agree, I don't know (other than history) why we couldn't move towards removing `PassManagerBuilder.SizeLevel`?

> Also, if size level is done via function attributes, why not optimization level? There is already `optnone`. I'm not saying that's better, but right now I don't see the logic in this whole system.

Despite what gcc and clang exposes to their users, at the LLVM level we don't have a single dimension on which to put `O1/O2/O3` compared to `Os/Oz`. These also may not make sense for every single compiler out-there: `O1/O2/O3` for clang may not be the right pass pipeline for my proprietary shader compiler.
Another reason why O1 <https://reviews.llvm.org/owners/package/1/>/O2 <https://reviews.llvm.org/owners/package/2/>/O3 <https://reviews.llvm.org/owners/package/3/> are not making much such to be in the IR is that the IR is intended to be stored and reloaded any time in the middle of pipeline. LTO is an example of this, so we don't really want to store the "list of pass to run" in the IR.
Finally, we don't want to (or we can't really...) teach passes about whether they should execute during O1 <https://reviews.llvm.org/owners/package/1/>/O2 <https://reviews.llvm.org/owners/package/2/>/O3 <https://reviews.llvm.org/owners/package/3/>, while `optnone` is just a "fuse" to disable them all. It is also convenient to have `optnone` as a function attribute because it allows to selectively disable the optimizer on a per function basis. On the other hand because of the nature of the pass pipeline, it can't be tweaked on a per function basis (what about Module passes?).

On the other hand the optsize/minsize are driving heuristic and can be orthogonal to the pass pipeline / controlled on a per-function basis and made available to every pass: they convey an "optimization goal" that applies to every pass individually.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list