<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/76762>76762</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Some print/verify passes are blocked by optnone (and other gates) with NewPM
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            tools:opt
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            bjope
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          bjope
      </td>
    </tr>
</table>

<pre>
    As reported/discussed in https://discourse.llvm.org/t/need-usage-help-w-new-pass-manager-for-opt-analysis-natural-loop-information/75874 things like this that used to work with legacy PM:
```
clang -O0 -S -emit-llvm app.c -o foo.ll
opt -analyze --loops foo.ll
```
no longer works with new PM if just doing
```
clang -O0 -S -emit-llvm app.c -o foo.ll
opt -passes='print<loops>' --disable-output foo.ll
```
By using `-debug-pass-manager` one could see that the print pass is skipped due to the functions being marked as "optnone". So when using O0 one can't analyze the IR unless bypassing the pass manager gates that for example check for optnone.

A workaround could be to use options like `disable-O0-optnone`, of a higher optimization level when generating the IR in the first place. But it feels wrong that it no longer is possible to run and print some analyses due to the pass manager gates. If using an explicit pipeline with print/verify passes I think it would be more correct to always print/verify the IR. Even if for example running the same printer pass more than once in a row.

The way to solve this is probably to use the `isRequired()` method to print and verify passes that currently lack that override. That is how we bypass the pass manager gates (e.g. optnone) for certain passes already today. And it is probably a mistake that we haven't done that for all print and verify passes.

PS. The discourse thread linked above also mentions that `print<loops>` used to print the name of the function containing the loops when using the legacy PM. This is another thing that seems to have disappeared with the new PM, and that could be solved as part of this issue.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJysVs1u2zoTfRp6M5AgS45_Fl6kPway6Neg6QuMpJHEmuLoIymr7tNfDCWncYPe1QWC2KYpnjPnnBkavdetJTqqhw8qz8sfPJDKc_XwaYVj6Ngd49Kq5Pp6fPTgaGAXqFb5qda-Gr2nGrSFLoTBq-JR5aflKx6dp9SYS5-ya1V-Cio_WaI6GT22lHRkhmRKLE3JgN4nPVpsySUNu4SHkKBFc_XaJxbD6NAkhnlItG3Y9Rg0W5Wfdg_73QZCp23rwegzyXsPocMAozALDBO7M0w6dGCoxeoKz1-EZ_ZJZY9qmy1_8WNl0LaQfM0geYGEeh0S4Q84DGkFCUPDnBozb-YhwEzyF0ES2fm7DX8cbhkM25ZcZORnSpYmeP4CuoEfow9Qs7btf0RNRCWvik8q3w1O26CKj5GkKj6rfAdJUmuPpaGExzCM4d-4f7jC6LVtQW2zpKZybO88U9sM2BJUPJoaPNHsQOgIIjLIZtAe_FkPA9VQjyTWyIZmtJW46aEkQejRnakG9KDynIdg2UogU3hhmDqyC5GvCyJale8C3HyQE5--wWgNeQ_lVYBle6QiJBbG0GKgJSgNO6Cf2A-GoOqoOseVBTpd9Ij_H6N16Hi09VJsGQsZPckDsYwYQ7XNbup-zZJbGdtM5R-BG0DodNtRRNG9_hXzDIYuZOYiW7LkMNyoP32THotyaecDDAYrSuHDGEAHaIiMh8lx3I1x7XfatIeBvdeliVTdaAFtvRjjuadZPE_-rS3vxUrhqVnERwv0czC60gEGPZDRluY8z0HLTxdyurnCnEF4ii16Fl7TTbWenQTGOaqCgKKZ8Or_PGAuPoXPF7LSJW-9cqO1N4E89kvWyC3c5fzQoQW2FYl8CI6nOz-_dwQTXgXes7ks00MEc1xiaa43bwVCbTPtv9H_R-1k_O1VfpDc9xQ6joNmVlS0va8-WlKNzpEN5goGq_O8xhdyTteUwvfomoeOJ5hoye3fQqvyPaVtCq_NcYiyVOQCantDReMIa6mgxmsKj7YW-d_WhtBrH_C8dOtE0OGF5n6qpbleuwON-Vt1d3o-v0gpBK_jH0InLMBoG5u65AsBGs_Qk53bJYKobfZuRG2z1xE-Y4scVnzm5m5yQMVWKr9lYZ7Eb2ZFXLzNfmE4m4yWg_RgvD5mHp6o94IoSkgZOAyEjuo53ZFBnNjSx6LF7O0t0zFEcXYN6MLMM2L5kdJVfSzqQ3HAFR3Xu2yTF7vssF91R6w3TXGgusDNDpvt4fDQ4GFf5-VDs98Wh2alj3mWb7J1lufFel3s0w2W-wJ366LJ14f1Zqc2GfWozettu4qQx912t81XBksyfrngA7ORe5qHsFzz7ihPJeXYerXJjPbB_z4n6GDo-MK37nrX2ugISsOV2Fteb5mUjIo8s8AxthLTKOL_aHr-shqdOd7_Zmh16MYyrbhX-UkILC_J4PgHVQIdq_Jy70th_wQAAP__PNz8Rw">