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

    <tr>
        <th>Summary</th>
        <td>
            Non-intuitive behavior of PGO flag modifiers
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

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

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

<pre>
    Hi!

During the Redis PGO optimization, I found a non-intuitive flags behavior when I compiled Redis with the `CC=clang CFLAGS="-fprofile-generate=/home/zamazan4ik/open_source/redis_profiles/redis-%p-%m.profraw" LDFLAGS="-fprofile-generate=/home/zamazan4ik/open_source/redis_profiles/redis-%p-%m.profraw" make -j24`, Clang surprisingly for me doesn't dump PGO profiles to a disk. When I ran the instrumented `redis-server` binary, I got the following warning in the logs:

> LLVM Profile Warning: %m specifier can only be specified once in /home/zamazan4ik/open_source/redis_profiles/redis-%p-%m.profraw/default_%m.profraw

According to my quick search through the sources, I found the corresponding line for the warning: [click](https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/profile/InstrProfilingFile.c#L838). According to these two pieces of documentation ([one](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program), [two](https://clang.llvm.org/docs/UsersManual.html#cmdoption-fprofile-generate)) it's possible to reverse the compiler logic - the `%m` modifier was specified twice in this case: explicitly in `redis-%p-%m` and implicitly in `default_%m.profraw`. However, now it's not a straightforward behavior, to be honest - I spent half an hour figuring out why the compiler doesn't save PGO profiles to a disk.

I have several proposals about how the situation can be improved:

* Make documentation more clear about this case. Maybe it's possible to merge somehow the documentation https://clang.llvm.org/docs/SourceBasedCodeCoverage.html with the main user guide about PGO. Searching for such information on one page about one thing is much simpler than jumping over cross-references.
* In cases when the PGO path is specified during the compilation, implement a warning when `%m` is specified more than one time. It will make it easier to understand the problem before the actual program run.
* Maybe it will be a good idea to consider removing the "The merge pool specifier (%m) can only occur once per filename pattern" limitation from the current PGO implementation in Clang.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy8VluP27wR_TX0y8CCTV_WfvDDXupkgd0maNrmMaCokcQsyVFJyqrz64uhfNs0fQj64QMWFpaXuZw5c4YqRtN4xJ1YPYjV00T1qaWw-6Gc-qH80rxNSqqOu49GyLmYPYnZ_fj71AfjG0gtwt-wMhE-f_gE1CXjzA-VDHkhH-EZaup9BQo8-anxqTfJHBBqq5oIJbbqYCjA0KKHZ9DkOmOxOhkcTGqzfbGePT6KxZO2yjfwuH-5__BFLJ6ElNO6C1Qbi9MGPQaVMK_vW3Io5P6ahJB76tB_i9QHzVuBXXw73Y7nhamQq45_XMFbQQ1CSnh5-tNdOvWGMP0ul2I9YyAfc-qxD10w0fjGHqGmAA6hIoxeyLsEVe-6XIWzC0gECioT3wr4OkIclM-QGh9T6B36hBXjO4YSMRwwiPUMSuNVOI4lbCjlOzVZSwMXfVDB89eMxiw1USzub9khFn-Bl5d_vsLnMRb4Ol4Ri3vgXCF2qE1tMIBWHsjbI5R4Wa2AvOYo4Q9Gdl9hrXqbvr1bvgn8XmsKVWY2gTvCv3qj3yCiCprJGKhvRlKOzuMty3lZUwgYO_LZhjUec6F4a7iBYPWgrdFvYvUk5KZNqcsAyr2Q-8akti8LTU7IvbWH82faBfqOOgm5Ly2VQu6dMl7I_altwjTwnjW8dcJCyP0zV3qsgvHN3lgstJCLl81iI-S2gHcJpxYjQhoIOoMaI1ANFelMlNzUIORGrB7I469Czw1acLAFhYbRJs3l-JKxelARq0eq8JEOGFSDRZucFXIRes_ATFOL01ticsZNUE7ILcMsVg9poN_x-4-IIb4q3yt79qVdxSJF_hd9zG62YJKQdxE6itGUFhmWgAcMDEwu8Ig2s95omJ4VignFneOoGnk9qHjD5zSYkdCpNRG0isg8wH931miT7DFz_dyHF-KyQeUrMO6nc7-k8XpWwEcaOFjGy9NwTsZTAgUxBWWaNtUUBhWqi_7y4UTcfy15jAmm8Myh-wStsjUoDy31AWrTjKJPfYKhPb7H4ypEUR3wfwnRba89Q8snIwesLJ_uKCobQZXsoaVh7DST-pF8LBUlMhqBDlj9rDnyHl5ZN98z1lFA0BZVONm9VKCAV3Vke_9dcYeh4R53eI7ivdH_n_fX8cZtDH3EAE1vKjxF-fnDpwK-ZN1hyFlEYq9bML6m4MYo8h9Cp5rzLf435QsmguPzkbmDrEDKw_fedbmABxbeQDFOA9YY0GuMxRXGZ58BiuNk5iBzOVVq2e6V1dX1ETDy4DL5s1fGC9RlXGRjN63yzlQuUw4y52AcFvCcYDDWjtPQJEAVubMSQe8rDDGpk-p2gUqLDkqsRzMISqd-JBVLCITeF7c0Ges-mi8RFDREFZgKFZvX5KOpMEBAR4dzikLKv3O9Mjc6InszxVgXOS25vQ400roP4yTrkNvHoleO65USBs9z3hpnTpSqA7kRyT4EBo4hv8A4njF-fAkUk2q3qLaLrZrgbn4328j5ej2fT9rdYik3G72u7ha43ZTr7WK91iusaiW323IptxOzkzO5nMn5ZjZbrFfzosTNZn23WeKslPOVVmI5Q6eMvfB5YmLscbeR8-VsYlWJNubHopQeB8ibQkp-O4ZdHlRl30SxnFkTU7xaSSZZ3P313Tvw8gKkOqfL78KLgsZJH-zut4djDoi7Lwf8nwAAAP__jMq1hg">