llvm-project.git/llvm/lib/CodeGen/MIRFSDiscriminator.cpp, branch users/nico/python-2 Unnamed repository; edit this file 'description' to name the repository. Move global namespace cl::opt inside llvm:: or internalize them 2023-10-11T02:58:03+00:00 Fangrui Song i@maskray.me 2023-10-11T02:58:03+00:00 2d854dd3e7c5a86ec5c37347ab326b8fa578d938 






[FSAFDO] Switch to xxh3_64bits
2023-07-19T21:23:28+00:00

Fangrui Song
i@maskray.me

2023-07-19T21:23:28+00:00

30e753dd07d9c66f6860e8ffcfbbda41155af975

Following recent changes switching from xxh64 to xxh32 for better
hashing performance. This particular instance may or may not have
noticeable performance difference, but this change makes us toward
removing xxHash64.





Following recent changes switching from xxh64 to xxh32 for better
hashing performance. This particular instance may or may not have
noticeable performance difference, but this change makes us toward
removing xxHash64.







[FS-AFDO] Clean up non-zero discriminator for pseudo probes at the first FS discriminator pass.
2023-05-17T04:35:17+00:00

Hongtao Yu
hoy@fb.com

2023-05-17T00:26:43+00:00

d4d6b9a142f0017b4d5668155fbbe045c838b8a6

The dwarf discriminator field for pseudo probes is not supposed to be used until the first FS discriminator pass. Unfortunately there are always corner cases that accidientally set this field. For example, the inliner could set this field for an inlined instruction if the instruction does not come with any debug information. While fixing all such spots is possible, but for future-proff I'd like to enforce a general cleanup before assigning probes any FS discriminator.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D150741





The dwarf discriminator field for pseudo probes is not supposed to be used until the first FS discriminator pass. Unfortunately there are always corner cases that accidientally set this field. For example, the inliner could set this field for an inlined instruction if the instruction does not come with any debug information. While fixing all such spots is possible, but for future-proff I'd like to enforce a general cleanup before assigning probes any FS discriminator.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D150741







[FS-AFDO] Assign discriminators to pseudo probes
2023-04-05T00:04:37+00:00

Hongtao Yu
hoy@fb.com

2023-03-31T00:36:51+00:00

5b461d5ec172d21029da492064704fe3da6f8bab

This is the first change for FS-AFDO integration with CSSPGO. There are more patches coming.

With pseudo probes, we do not assign FS discriminators to any other instructions since we will be using only probes for profile correlation.

Also call instructions are excluded since their dwarf discriminators are used for other purposes, i.e, storing probe ids. Since they are not getting a FS discriminator, they will also be excluded from MIR profile loading. The corresponding changes will be in the subsequent patches.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D147286





This is the first change for FS-AFDO integration with CSSPGO. There are more patches coming.

With pseudo probes, we do not assign FS discriminators to any other instructions since we will be using only probes for profile correlation.

Also call instructions are excluded since their dwarf discriminators are used for other purposes, i.e, storing probe ids. Since they are not getting a FS discriminator, they will also be excluded from MIR profile loading. The corresponding changes will be in the subsequent patches.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D147286







[FSAFDO] Improve FS discriminator encoding
2023-03-10T07:18:48+00:00

Rong Xu
xur@google.com

2023-03-10T06:43:08+00:00

ebe09e2a9556c411809f6c27f555299273442664

This change improves FS discriminators in the following ways:
(1) use call-stack debug information in the the to generate
discriminators: the same (src/line) DILs can now have same
discriminator value if they come from different call-stacks.
This effectively increases the usable discriminator values
for each round of FS discriminator pass.
(2) don't generate the FS discriminator for meta instructions
(i.e. instructions not emitted). This reduces the number
discriminators conflicts (for the case we run out of discriminator
bits for that pass).
(3) use less expensive hashing of xxHash64.

These improvements should bring better performance for FSAFDO
and they should be used by default. But this change creates
incompatible FS discriminators. For the iterative profile users,
they might see a performance drop in the first release with
this change (due to the fact that the profiles have the old
discriminators and the compiler uses the new discriminator).
We have measured that this is not more than 1.5% on several
benchmarks. Note the degradation should be gone in the second
release and one should expect a performance gain over the binary
without this change.

One possible solution to the iterative profile issue would be
separating discriminators for profile-use and the ones emitted to
the binary. This would require a mechanism to allow two sets of
discriminators to be maintained and then phasing out the first
approach. This is too much churn in the compiler and the
performance implications do not seem to be worth the effort.

Instead, we put the changes under an option so iterative profile
users can do a gradual rollout of this change. We will make the
option default value to true in a later patch and eventually
purge this option from the code base.

Differential Revision: https://reviews.llvm.org/D145171





This change improves FS discriminators in the following ways:
(1) use call-stack debug information in the the to generate
discriminators: the same (src/line) DILs can now have same
discriminator value if they come from different call-stacks.
This effectively increases the usable discriminator values
for each round of FS discriminator pass.
(2) don't generate the FS discriminator for meta instructions
(i.e. instructions not emitted). This reduces the number
discriminators conflicts (for the case we run out of discriminator
bits for that pass).
(3) use less expensive hashing of xxHash64.

These improvements should bring better performance for FSAFDO
and they should be used by default. But this change creates
incompatible FS discriminators. For the iterative profile users,
they might see a performance drop in the first release with
this change (due to the fact that the profiles have the old
discriminators and the compiler uses the new discriminator).
We have measured that this is not more than 1.5% on several
benchmarks. Note the degradation should be gone in the second
release and one should expect a performance gain over the binary
without this change.

One possible solution to the iterative profile issue would be
separating discriminators for profile-use and the ones emitted to
the binary. This would require a mechanism to allow two sets of
discriminators to be maintained and then phasing out the first
approach. This is too much churn in the compiler and the
performance implications do not seem to be worth the effort.

Instead, we put the changes under an option so iterative profile
users can do a gradual rollout of this change. We will make the
option default value to true in a later patch and eventually
purge this option from the code base.

Differential Revision: https://reviews.llvm.org/D145171







[NFC] Rename Function::isDebugInfoForProfiling to shouldEmit[...]
2022-12-22T02:36:59+00:00

Mircea Trofin
mtrofin@google.com

2022-12-22T02:36:59+00:00

946831ea2d7717a56383e284426527bc6de3808d

The function name was misleading - the expectation set both by the name
and by other members of Function (like isDeclaration or isIntrinsic)
would be that the function somehow would "be" "debug info for
profiling". But that's not the case - the property indicates (as the
comment over the declaration also explains) whether debug info should be
emitted (for profiling).





The function name was misleading - the expectation set both by the name
and by other members of Function (like isDeclaration or isIntrinsic)
would be that the function somehow would "be" "debug info for
profiling". But that's not the case - the property indicates (as the
comment over the declaration also explains) whether debug info should be
emitted (for profiling).







Fix warnings about variables that are set but only used in debug mode
2022-04-06T07:01:46+00:00

Martin Storsjö
martin@martin.st

2022-04-05T08:34:05+00:00

46776f7556a337ebf210b1cac838bca2aaa15351

Add void casts to mark the variables used, next to the places where
they are used in assert or `LLVM_DEBUG()` expressions.

Differential Revision: https://reviews.llvm.org/D123117





Add void casts to mark the variables used, next to the places where
they are used in assert or `LLVM_DEBUG()` expressions.

Differential Revision: https://reviews.llvm.org/D123117







Cleanup codegen includes
2022-03-16T07:43:00+00:00

serge-sans-paille
sguelton@redhat.com

2022-03-15T09:54:19+00:00

989f1c72e0f4236ac35a35cc9998ea34bc62d5cd

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after:  1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681





This is a (fixed) recommit of https://reviews.llvm.org/D121169

after:  1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681







Revert "Cleanup codegen includes"
2022-03-10T12:59:22+00:00

Nico Weber
thakis@chromium.org

2022-03-10T12:54:41+00:00

a278250b0f85949d4f98e641786e5eb2b540c6b0

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169





This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169







Cleanup codegen includes
2022-03-10T09:00:30+00:00

serge-sans-paille
sguelton@redhat.com

2022-03-07T23:25:52+00:00

7f230feeeac8a67b335f52bd2e900a05c6098f20

after:  1061034926
before: 1063332844

Differential Revision: https://reviews.llvm.org/D121169





after:  1061034926
before: 1063332844

Differential Revision: https://reviews.llvm.org/D121169