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

    <tr>
        <th>Summary</th>
        <td>
            Runaway inlining with new pass manager.
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
      </td>
    </tr>

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

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

<pre>
    I'm looking at the code generated for `yaml_parser_fetch_more_tokens` in https://github.com/oracle/truffleruby/blob/4054469bbd985db7dc5c86299004ff86a2835baf/src/main/c/psych/yaml/scanner.c (to reproduce, you just need this file, `yaml.h` and `yaml_private.h` next to it).

I'm compiling the file with `clang -S -emit-llvm -I. -O1 scanner.c` (the `-O` level doesn't really matter, as long as it's not `-O0`).

Looking at the resulting bitcode of `yaml_parser_fetch_more_tokens`, it's huge, ~3500 bitcode instructions. Also, the first basic block consists of just 60 `alloca`, and then a mix of 700 `bitcast` and `getelementptr` instructions. Many of them are used later, all over the rest of the function. As far as I can tell, the bitcode is correct, just a lot bigger than expected.

Compiling the same function with `-flegacy-pass-manager -O1`, it looks totally fine, just ~40 bitcode instructions. Even with `-flegacy-pass-manager -O3` it’s only sligthly bigger, ~70 bitcode instructions.

Running with `-mllvm --print-changed=quiet -mllvm --filter-print-funcs=yaml_parser_fetch_more_tokens` shows that it is the inliner that's blowing up (thanks @aeubanks for pointing out these flags on discourse).

Even if this is just the known "doing some inlining at -O1" difference in the new pass manager, I think this is way too aggressive, even for `-O3`, let alone `-O1`. Even if the code size is considered ok, I don't think it makes sense to have that many GEPs in the first block, because that just leads to a lot of spilling.

I did my tests with LLVM 14.0.3, plus various different LLVM revisions. I actually bisected the issue to the commit enabling the new pass manager by default, so the bug seems to be in the new pass manager for at least as long as it's enabled by default. Everything on `linux/x86_64` in case it makes a difference.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyNVt1vozgQ_2vIixVECITkIQ-9bfdUaVd7upPutTJmAG-MnfOYtNm__mYMSdquentSFEhsz8fvY6B2zXn_mOTVIIxzB207IYMIPQjlGhAdWPAyQCNa50Wyyc5yME9H6RH8UwtB9U-D8_AU3AEs0rrQVvQhHDFZ3yX5Z_p0OvRjnSo30A_npTJAN8GPbWvAj_WZftXG1XQpsrIoNru6bnbbsqmrRpVqu8l3uywr2na7kfl2Xdaypa3oFX0PUlu68O0Rz6qnKxfI60paKj1VIsm3wQkPR--aUVHuT-LsRvF9xCAsUGeh1yhabeLS3GLacy_SNreevT4RENOChRcCyQkdknyXJtl9kt1N3xOU1OxRGwaTkeTY4plg4GDKSPp7-ZdYwqDD0pjTIJaPqVh-W4lr0ZyD66bDdLv8xr8NnMCIxgFSy1WgjqQxZzHIEMBz6RKJQuYPY10VCuvCdD6j7_eVfnlLtwccTeA_ah0i9679P4Rz5jldP3YThtXDusyyayBtkehWQTuLqbgz6HjXhIwnFmqJWgnSgDoQchY1BuTskSJGYpNRq07JOR3TQqetkGLQL7yzyuIuTigxvKKugwAGBrDhGPwkz9e1fJX2zOcp2iCkBzEiCcLIC6LGCHcCfwEozHtFO9oYgroh6UjPmD8KYk9QOnPp7to_Ulvegwq8EruSRBU1rrsuRqeD8HKkDdC84ejTGx2hHG6pr4Jako06qc7Lo0RcDtJKjklyupITnY2k1xAV02oL10KIq-Ijph5O8Os064hqSB7yZJslux0xZykJGt2Fnm6mHmdZVB-ket3zn6O13PE18TB5ZEkOtGGpCKwOmmR9_8-oIYjrMrmMaJt3MUo0gu5_Oa6wd8_IDAQGSmMEWlvCfCJmUjZp85lrGo-TLaUlPJMikzDW8Z6n49FRZt7lxmgpJLKM7BgQ0WhUbqQy3rswYqzbaQjRJ5LCNRyse7aULW8cx0Q3zHXNnmWC85wCty14sIpX40ELz4I5EjNHDP0jx7eHa5ZneSY5OCG7jmSN-hQFAVzLPOcnYvlfQyBLGizzKGJZzdLQ7e1BgfrHLHTyb0MVNcIdptSNmwbWVAKhPMgDoEBiAHiI9vIEEwMD2_H3hz_w0ss8H3gycKwalBxx3hyRMiAbVvZsKLInkmHYMW-nMuHUiIGaBp4tUVpfvvz9VayKNEvXHPtoRhQn6bWj6wXVMO3ycNI4eeJRSBXG6KNaY3TsJBnEMXYzITLQbBdgZX0173taRH0WDbSShi6nx-lkPRLVAEPsqf6Q08iSjO3zMPlp8MfMVNktR6TMn5mDjgVJLFJp4ws9Kl-2m6dNMT-7aX7CjSP5Sl_pAvarTbnbVXlV5Ytmv252651cBB0M7Mm1klV1lWjE-H3d6WL0Zv8f7wfs5flCTnbf48z8HMFFuilp0G8W_T5b5TtoylxVqoaV3BZtsVJ5BrIqtqu6VQsjazC4T8rfkvJ-ofd5lufZNtuuynVertK23FS5KqFdbYpss8rIykDvEiblxKnz3cLvYw3EB9Ki4UfSbZE60h29O1ziyzH0zu890nAKPxax3H2s9V_wfiF-">