gh-bitflags/bitflags
Watch
1
0
Fork
You've already forked bitflags
 0
Code Issues 10 Pull requests Releases 53 Activity

all() causing LLVM bloat #491

New issue
Closed
opened 2026-06-30 12:08:06 -05:00 by bolshoytoster · 3 comments
bolshoytoster commented 2026-06-30 12:08:06 -05:00 (Migrated from github.com)

Currently, bitflags::all() outputs 6 + 20n lines of LLVM IR in debug builds, and 8 + 14n on release builds, where n is the number of flags. I first noticed this with wgpu's FeaturesWGPU, which has 58 flags (1166 lines debug, 820 release).

The implementation is here:
github.com/bitflags/bitflags@9253889ee9/src/public.rs (L150-L168)

If I wrap the function in const {} then the function emits only 1 line of IR in debug, and seems to be fully optimized away in release.

This bloat slows down builds (sllightly) and probably makes it less likely for some optimizations to occur (don't quote me on that, I'm not a compiler developer).

There are probably some other generated functions that suffer from this. I can investigate and open a PR if that's wanted.

Currently, bitflags::all() outputs `6 + 20n` lines of LLVM IR in debug builds, and `8 + 14n` on release builds, where `n` is the number of flags. I first noticed this with wgpu's [FeaturesWGPU](https://docs.rs/wgpu-types/latest/wgpu_types/struct.FeaturesWGPU.html), which has 58 flags (1166 lines debug, 820 release). The implementation is here: https://github.com/bitflags/bitflags/blob/9253889ee93921055309908c46272bd6c5c6ad99/src/public.rs#L150-L168 If I wrap the function in `const {}` then the function emits only 1 line of IR in debug, and seems to be fully optimized away in release. This bloat slows down builds (sllightly) and probably makes it less likely for some optimizations to occur (don't quote me on that, I'm not a compiler developer). There are probably some other generated functions that suffer from this. I can investigate and open a PR if that's wanted.
bolshoytoster commented 2026-06-30 12:46:49 -05:00 (Migrated from github.com)

from_name is also fairly big 13 + 7n debug, 12 + 14n release (not a typo, it's way bigger in release). I can get it down to 13 + 6n and 13 + 12n release by changing $PublicBitFlags::$Flag.bits() to $value (only affected debug), and changing the list of if statements to a match (only affected release).

`from_name` is also fairly big `13 + 7n` debug, `12 + 14n` release (not a typo, it's way bigger in release). I can get it down to `13 + 6n` and `13 + 12n` release by changing `$PublicBitFlags::$Flag.bits()` to `$value` (only affected debug), and changing the list of if statements to a match (only affected release).
KodrAus commented 2026-06-30 17:11:54 -05:00 (Migrated from github.com)

Thanks for investigating this @bolshoytoster! Would you be happy to open a PR with your improvements and we can take a look? We should be aiming for as small a footprint as possible.

Thanks for investigating this @bolshoytoster! Would you be happy to open a PR with your improvements and we can take a look? We should be aiming for as small a footprint as possible.
👍 1
bolshoytoster commented 2026-07-01 04:26:56 -05:00 (Migrated from github.com)

I've opened a PR (#492)

I've opened a PR (#492)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
release/1.x
2.13.2
2.13.1
2.13.0
2.12.1
2.12.0
2.11.1
2.11.0
2.10.0
2.9.4
2.9.3
2.9.2
2.9.1
2.9.0
2.8.0
2.7.0
2.6.0
2.5.0
2.4.2
2.4.1
2.4.0
2.3.3
2.3.2
2.3.1
2.3.0
2.2.1
2.2.0
2.1.0
2.0.2
2.0.1
2.0.0
2.0.0-rc.3
2.0.0-rc.2
2.0.0-rc.1
1.3.2
1.3.1
1.3.0
1.2.1
1.2.0
1.1.0
1.0.5
1.0.4
1.0.3
1.0.2
1.0.1
1.0.0
0.9.1
0.9.0
0.8.2
0.8.1
0.8.0
0.7.1
0.7.0
0.6.0
Labels
Clear labels   
bug

   
good first issue
No labels
bug
good first issue
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-bitflags/bitflags#491
No description provided.