Introducing Profi into Rustc for better Sample PGO quality

[zamazan4ik]

Hi!

Profi is an algorithm for improving Sample PGO profile quality by clever heuristics (more details read in the Reference in "Profi implementation". This functionality is already implemented in LLVM and integrated into Clang's PGO pipeline. Rust is lacking such of functionality for now.

Clang has -fsample-profile-use-profi flag. Clang already enabled using Profi default for Sample PGO use case 1 year.

At the moment, Profi can still be used with Rust by passing an additional LLVM flag: -Cllvm-args=-sample-profile-use-profi but I haven't tested it with Rustc yet.

Open questions:

• Do we want to introduce an alternative to -fsample-profile-use-profi/-fno-sample-profile-use-profi into the Rustc compiler?
• Do we want to enable Profi for Sample PGO by default? If yes, do we need to introduce flags to disable this behavior explicitly (see previous point). In this case, we can provide better Sample PGO experience for an average user - they don't need to know about an additional hidden LLVM argument that improves Sample PGO quality. At the moment, I have a draft commit about enabling it by default in my Rust fork: commit. We can partially mitigate it by adding such flags as a part of cargo-pgo but it's another discussion topic (especially since cargo-pgo doesn't support Sample PGO flow).
• Do we need more evidence about Profi efficiency from practice? It's kinda difficult to find any evidency even for Clang. But in theory, Profi is a good idea.

Some references:

• Profi implementation commits in LLVM: one, two, three
• Adding -fsample-profile-use-profi flag into Clang: commit
• Enabling using Profi by default in Clang: PR
• Adding -fno-sample-profile-use-profi flag: PR
• Some benchmarks about Profi efficiency: ChromeOS results, more results

Kindly pinging @ojeda since that functionality could be interesting for their use case too (even if seems like Google uses another approach internally). Maybe this approach with flow-sensitive discriminators should be pushed instead? Especially since exactly this approach is used in Rust-for-Linux.

Thank you.

[ojeda]

Profi implementation commits in LLVM: one, two, three

"three" should point to llvm/llvm-project@93a2c2919f73

Do we want to enable Profi for Sample PGO by default?

If Clang does it by default, then it sounds like it is a reasonable proposal. However:

Do we need more evidence about Profi efficiency from practice? It's kinda difficult to find any evidency even for Clang. But in theory, Profi is a good idea.

...that sounds like the main question :)

Kindly pinging @ojeda since that functionality could be interesting for their use case too (even if seems like Google uses llvm/llvm-project#145957 (comment) approach internally). Maybe this approach with flow-sensitive discriminators should be pushed instead? Especially since exactly this approach is used in Rust-for-Linux.

Let me forward this to Rong, Han et al. via email. Cc'ing @nikic too. They may have more context and/or recent data.

[Darksonn]

Yeah I think we should have the same defaults as clang on this area.

[xur-llvm]

There are a few different favors of Sample PGO (or AutoFDO) in Clang. In the original version (debug info based), Profi is not enabled by default. However, Profi is enabled by default for CSSPGO (context-sestive) or Probe-based SamplePGO.

The version we used in kernel build is FS-AFDO -- this is based on the original Sample PGO (debuginfo based).

In our AutoFDO patch to upstream kernel, we did not enable Profi. We observed this degradation in userland
applications. As you probably know, FS-AFDO is widely deployed at Google for user applications. Adding Profi on top did not yield improvements; instead, it resulted in a slight performance regression.

We have a theory about this, but we haven't yet had the opportunity to verify or address it.

That said, we haven't tested this in the kernel since measuring performance there is significantly more difficult than in user
applications. If there is evidence that Profi enhances kernel performance, we would be happy to include this option.

-Rong

[zamazan4ik]

Thanks a lot for the comment!

However, Profi is enabled by default for CSSPGO (context-sestive) or Probe-based SamplePGO.

Just to be sure that I understand things correctly: is CSSPGO and Probe-based SamplePGO the same thing? As far as I understand - yes (and in the Clang PGO guide CSSPGO is described with using -fpseudo-probe-for-profiling flags).

Just want to clarify that here we are talking about regular, debuginfo-based Sample PGO.

There are a few different favors of Sample PGO (or AutoFDO) in Clang. In the original version (debug info based), Profi is not enabled by default. However, Profi is enabled by default for CSSPGO (context-sestive) or Probe-based SamplePGO.

Hm, but for me it's not clear from this PR. I am reading it as "we enabled Profi by default for SamplePGO". It says nowhere is that Profi is enabled by default only for CSSPGO. I've quickly checked the source code, and came to the same conclusion that Profi is enabled by default for a regular Sample PGO, not for CSSPGO. Am I wrong in my understanding here?

By the way, I think adding CSPGO and CSSPGO will be valuable for Rustc too to be on par with Clang but I suggest discussing this topic later in a separate issue (just don't wanna pollute this one).

[xur-llvm]

Ah. My information was outdated and I wasn't aware of that PR. So you are right, profi is on by default for clang, and I see the rationale for enabling it for rust as well. That said, I'm unclear on the decision to implement this within clang specifically. My approach would have been to handle it in LLVM by setting the internal option to true by default, which would avoid the need for changes across every front end. My statement about the interaction b/w FSAFDO and profi is still true. I checked our internal builds and verified that we explicitly disable profi for our debug-base SamplePGO for performance. Thanks,

…

-Rong

On Thu, May 28, 2026 at 10:13 PM Alexander Zaitsev ***@***.***> wrote: zamazan4ik left a comment (rust-lang/rust#156898) Thanks a lot for the comment! However, Profi is enabled by default for CSSPGO (context-sestive) or Probe-based SamplePGO. Just to be sure that I understand things correctly: is CSSPGO and Probe-based SamplePGO the same thing? As far as I understand - yes (and in the Clang PGO guide CSSPGO is described with using -fpseudo-probe-for-profiling flags). Just want to clarify that here we are talking about regular, debuginfo-based Sample PGO. There are a few different favors of Sample PGO (or AutoFDO) in Clang. In the original version (debug info based), Profi is not enabled by default. However, Profi is enabled by default for CSSPGO (context-sestive) or Probe-based SamplePGO. Hm, but for me it's not clear from this PR. I am reading it as "we enabled Profi by default for SamplePGO". It says nowhere is that Profi is enabled by default only for CSSPGO. I've quickly checked the source code, and came to the same conclusion that Profi is enabled by default for a regular Sample PGO, not for CSSPGO. Am I wrong in my understanding here? By the way, I think adding CSPGO and CSSPGO will be valuable for Rustc too to be on par with Clang but I suggest discussing this topic later in a separate issue (just don't wanna pollute this one). — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[zamazan4ik]

Ah. My information was outdated and I wasn't aware of that PR. So you
are right, profi is on by default for clang, and I see the rationale
for enabling it for rust as well.

Thanks for checking and proving, that my understanding is right :)

That said, I'm unclear on the decision to implement this within clang
specifically. My approach would have been to handle it in LLVM by
setting the internal option to true by default, which would avoid the
need for changes across every front end.

Fair point. If LLVM believes that this change is good for improving debuginfo-based Sample PGO in general (in general, not in all cases as you mentioned) - I think it would be nice to see it enabled there. I guess one of the reasons for the way it was implemented is that people actually doesn't care much about Sample PGO besides Clang nowadays. Sample PGO is relatively "hidden" technique at all, and with other compilers besides Clang it's almost in a non-existent state.

Knowing all the context above, I see multiple ways how we can proceed further with this issue.

1. Do not enable Profi by default for Sample PGO in Rustc

We simply leave the things as they are currently implemented in Rustc.

Pros:

• We don't need to change anything in the Rustc source code. However, enabling Profi by default should be kinda trivial task to do since it requires only passing an additional LLVM flag during the LLVM invocation inside Rustc
• For use cases, where Profi makes things worse (as @xur-llvm mentioned above) we don't need to implement a way to disable Profi. E.g. if we enable Profi by default, Rust-in-Linux will be required to pass some additional flag to disable Profi (see the kernel patch) - and such a flag doesn't exist yet either in Rustc - we will need to implement it.
• We leave room for improvements for the future. E.g. what if we decide to enable FS-AFDO approach by default instead of Profi in Rustc (see the 3rd option below)? Or provide two options at the same time to choose from. There are a variety of options here.

Cons:

• Our behaviour stays a bit different from Clang for the default Sample PGO case since by default Sample PGO in Clang will work a bit differently from Rustc. E.g. it influences Clang PGO guide reusability with Rustc (in ideal world, it shouldn't be even the case, but it is what it is for now)
• For use cases, where Profi improves Sample PGO efficiency (see my initial message in the topic), users will not get Profi-provided improvements by default. They will need to learn somehow about Profi existence (it means we'll need to update Rustc's PGO guide), pass flags properly, etc. - it makes Sample PGO developer experience a bit worse by default.

2. Enable Profi by default for Sample PGO in Rustc

With this approach, we enable Profi by default for Sample PGO in Rustc and make it consistent with Clang's behaviour.

Pros:

• Sample PGO users in Rustc will get benefits from Profi by default. It improves developers experience by default since they don't need to learn yet another hack to make Sample PGO a bit better.
• We stay in sync with Clang behaviour. It's a nice thing since Clang nowadays actually can/should be treated as a "reference LLVM frontend regarding PGO things" since most PGO developments are mostly done for C++ with Clang (thanks Google for the contribution).

Cons:

• It requires some implementation efforts. However, I don't expect anything significant here.
• For use cases, where Profi makes things worse, we will need to implement a way to disable it (see the Google case above). It could be a Rustc flag.

3. Enable FS-AFDO approach by default for Sample PGO in Rustc instead of Profi

This is a new option, where we instead of copying Clang behaviour choose another direction and enable FS-AFDO approach (with LLVM discriminators) by default instead of Profi. I would like to hear @xur-llvm about this one since I personally don't have much experience with this approach at the moment.

Pros:

• That's the way how Sample PGO is used inside Google - the largest Sample PGO user in the world nowadays, so we can trust pretty much their experience and feedback about this decision. Even if it's done mostly with Clang and C++ - the experience is totally applicable for the Rust case as well.
• Sample PGO users in Rustc will get benefits from FS-AFDO by default without needing to learn about yet another bunch of LLVM flags, ways how to pass it, etc. - it improves developers experience with Sample PGO by default.

Cons:

• Rustc becomes even more different from Clang regarding chosen defaults. It could lead to some surprises in the future regarding reusing Clang's Sample PGO experience/benches/etc. for Rustc.
• This option is not implemented anywhere by default so it's a bit more risky. I don't even know right now, is it a viable option or not. E.g. why it wasn't implemented by default in Clang instead of Profi? I don't have information about it - mayeb @xur-llvm can help here as well :)
• We need to implement it in Rustc somehow. As far as I understand, it shouldn't be a difficult task but anyway.

---

Knowing all the context above, I suggest start with the first option - "1. Do not enable Profi by default for Sample PGO in Rustc". It gives all Rust users flexibility regarding ways of doing Sample PGO: someone will choose Sample PGO + Profi, someone will choose Sample PGO via FS-AFDO way, someone can even stay with a regular Sample PGO. TL;DR we leave the Sample PGO features additive as we can.

One important thing is that we definitely need to document all of these details/nuances with different Sample PGO flavours in the Rustc Sample PGO documentation. If we agree with this approach, I am ready to do such a contribution into the documentation after landing #155942 In this PR, Sample PGO documentation in Rustc was heavily reworked, and after merge I can add missing documentation pieces regarding Profi, FS-AFDO, etc.

We still be able to enable Profi or FS-AFDO (or anything else) by default in the future - this ability will stay with us anyway. Users's default experience shouldn't be a big issue for now since Sample PGO is has pretty limited usage across the Rust ecosystem nowadays. Even if Rustc behaviour will stay different from Clang's - we can fix it any time in the future.

What do you think about this way?

[zamazan4ik]

@xur-llvm and I have a bit unrelated question about CSSPGO (I will create a separate Rustc issue for that one later).

Is CSSPGO and Probe-based SamplePGO the same thing? As far as I understand - yes (and in the Clang PGO guide CSSPGO is described with using -fpseudo-probe-for-profiling flags).

Just want to be sure that I my understanding is correct.