116

I have some code that is more or less like this:

#include <bitset> enum Flags { A = 1, B = 2, C = 3, D = 5, E = 8, F = 13, G = 21, H, I, J, K, L, M, N, O }; void apply_known_mask(std::bitset<64> &bits) { const Flags important_bits[] = { B, D, E, H, K, M, L, O }; std::remove_reference<decltype(bits)>::type mask{}; for (const auto& bit : important_bits) { mask.set(bit); } bits &= mask; } 

Clang >= 3.6 does the smart thing and compiles this to a single and instruction (which then gets inlined everywhere else):

apply_known_mask(std::bitset<64ul>&): # @apply_known_mask(std::bitset<64ul>&) and qword ptr [rdi], 775946532 ret 

But every version of GCC I've tried compiles this to an enormous mess that includes error handling that should be statically DCE'd. In other code, it will even place the important_bits equivalent as data in line with the code!

.LC0: .string "bitset::set" .LC1: .string "%s: __position (which is %zu) >= _Nb (which is %zu)" apply_known_mask(std::bitset<64ul>&): sub rsp, 40 xor esi, esi mov ecx, 2 movabs rax, 21474836482 mov QWORD PTR [rsp], rax mov r8d, 1 movabs rax, 94489280520 mov QWORD PTR [rsp+8], rax movabs rax, 115964117017 mov QWORD PTR [rsp+16], rax movabs rax, 124554051610 mov QWORD PTR [rsp+24], rax mov rax, rsp jmp .L2 .L3: mov edx, DWORD PTR [rax] mov rcx, rdx cmp edx, 63 ja .L7 .L2: mov rdx, r8 add rax, 4 sal rdx, cl lea rcx, [rsp+32] or rsi, rdx cmp rax, rcx jne .L3 and QWORD PTR [rdi], rsi add rsp, 40 ret .L7: mov ecx, 64 mov esi, OFFSET FLAT:.LC0 mov edi, OFFSET FLAT:.LC1 xor eax, eax call std::__throw_out_of_range_fmt(char const*, ...) 

How should I write this code so that both compilers can do the right thing? Failing that, how should I write this so that it remains clear, fast, and maintainable?

6
  • 4
    Rather than using a loop, can't you construct a mask with B | D | E | ... | O? Commented Feb 20, 2019 at 12:25
  • 6
    The enum has bit positions rather than already expanded bits, so I could do (1ULL << B) | ... | (1ULL << O) Commented Feb 20, 2019 at 12:26
  • 3
    The downside being that the actual names are long and irregular and it's not nearly as easy to see which flags are in the mask with all that line noise. Commented Feb 20, 2019 at 12:32
  • 4
    @AlexReinking You could make it one (1ULL << Constant) | per line, and align the constant names on the different lines, that would be easier on the eyes. Commented Feb 21, 2019 at 15:37
  • I think problem here related to lack of use unsigned type,GCC always had troubles with statically discarding correction for overflow and type conversion in signed/unsigned hybrid.Result of bit shift here is an int result of bit operation MAY BE int OR may be long long depending on value and formallyenum isn't an equivalent to a an int constant. clang calls for "as if", gcc stays pedantic Commented Feb 28, 2020 at 8:43

6 Answers 6

118

Best version is :

template< unsigned char... indexes > constexpr unsigned long long mask(){ return ((1ull<<indexes)|...|0ull); } 

Then

void apply_known_mask(std::bitset<64> &bits) { constexpr auto m = mask<B,D,E,H,K,M,L,O>(); bits &= m; } 

back in , we can do this strange trick:

template< unsigned char... indexes > constexpr unsigned long long mask(){ auto r = 0ull; using discard_t = int[]; // data never used // value never used: discard_t discard = {0,(void( r |= (1ull << indexes) // side effect, used ),0)...}; (void)discard; // block unused var warnings return r; } 

or, if we are stuck with , we can solve it recursively:

constexpr unsigned long long mask(){ return 0; } template<class...Tail> constexpr unsigned long long mask(unsigned char b0, Tail...tail){ return (1ull<<b0) | mask(tail...); } template< unsigned char... indexes > constexpr unsigned long long mask(){ return mask(indexes...); } 

Godbolt with all 3 -- you can switch CPP_VERSION define, and get identical assembly.

In practice I'd use the most modern I could. 14 beats 11 because we don't have recursion and hence O(n^2) symbol length (which can explode compile time and compiler memory usage); 17 beats 14 because the compiler doesn't have to dead-code-eliminate that array, and that array trick is just ugly.

Of these 14 is the most confusing. Here we create an anonymous array of all 0s, meanwhile as a side effect construct our result, then discard the array. The discarded array has a number of 0s in it equal to the size of our pack, plus 1 (which we add so we can handle empty packs).


A detailed explanation of what the version is doing. This is a trick/hack, and the fact you have to do this to expand parameters packs with efficiency in C++14 is one of the reasons why fold expressions were added in .

It is best understood from the inside out:

 r |= (1ull << indexes) // side effect, used 

this just updates r with 1<<indexes for a fixed index. indexes is a parameter pack, so we'll have to expand it.

The rest of the work is to provide a parameter pack to expand indexes inside of.

One step out:

(void( r |= (1ull << indexes) // side effect, used ),0) 

here we cast our expression to void, indicating we don't care about its return value (we just want the side effect of setting r -- in C++, expressions like a |= b also return the value they set a to).

Then we use the comma operator , and 0 to discard the void "value", and return the value 0. So this is an expression whose value is 0 and as a side effect of calculating 0 it sets a bit in r.

 int discard[] = {0,(void( r |= (1ull << indexes) // side effect, used ),0)...}; 

At this point, we expand the parameter pack indexes. So we get:

 { 0, (expression that sets a bit and returns 0), (expression that sets a bit and returns 0), [...] (expression that sets a bit and returns 0), } 

in the {}. This use of , is not the comma operator, but rather the array element separator. This is sizeof...(indexes)+1 0s, which also set bits in r as a side effect. We then assign the {} array construction instructions to an array discard.

Next we cast discard to void -- most compilers will warn you if you create a variable and never read it. All compilers will not complain if you cast it to void, it is sort of a way to say "Yes, I know, I'm not using this", so it suppresses the warning.

Sign up to request clarification or add additional context in comments.

15 Comments

Sorry, but that C++14 code is something. I don't know what.
@James It is a wonderful motivating example of why fold expressions in C++17 are very welcome. It, and similar tricks, turn out to be an efficient way to expand a pack "inplace" without any recursion and that compliers find easy to optimize.
@ruben multi line constexpr is illegal in 11
I can't see myself checking in that C++14 code. I'll stick to the C++11 one since I need that, anyway, but even if I could use it, the C++14 code requires so much explanation I wouldn't. These masks can always be written to have at most 32 elements, so I'm not worried about O(n^2) behavior. After all, if n is bounded by a constant, then it's really O(1). ;)
To those trying to understand ((1ull<<indexes)|...|0ull) it is a "fold expression". Specifically it is a "binary right fold" and It should be parsed as (pack op ... op init)
|
48

The optimization you're looking for seems to be loop peeling, which is enabled at -O3, or manually with -fpeel-loops. I'm not sure why this falls under the purview of loop peeling rather than loop unrolling, but possibly it's unwilling to unroll a loop with nonlocal control flow inside it (as there is, potentially, from the range check).

By default, though, GCC stops short of being able to peel all the iterations, which apparently is necessary. Experimentally, passing -O2 -fpeel-loops --param max-peeled-insns=200 (the default value is 100) gets the job done with your original code: https://godbolt.org/z/NNWrga

3 Comments

You are amazing thank you! I had no idea this was configurable in GCC! Though for some reason -O3 -fpeel-loops --param max-peeled-insns=200 fails... It's due to -ftree-slp-vectorize apparently.
This solution seems to be limited to the x86-64 target. The output for ARM and ARM64 is still not pretty, which then again might be completely irrelevant for OP.
@realtime - it is somewhat relevant, actually. Thanks for pointing out that it doesn't work in this case. Very disappointing that GCC doesn't catch it before being lowered to a platform-specific IR. LLVM optimizes it before any further lowering.
10

if using only C++11 is a must (&a)[N] is a way to capture arrays. This allows you to write one single recursive function without using helper functions whatsoever:

template <std::size_t N> constexpr std::uint64_t generate_mask(Flags const (&a)[N], std::size_t i = 0u){ return i < N ? (1ull << a[i] | generate_mask(a, i + 1u)) : 0ull; } 

assigning it to a constexpr auto:

void apply_known_mask(std::bitset<64>& bits) { constexpr const Flags important_bits[] = { B, D, E, H, K, M, L, O }; constexpr auto m = generate_mask(important_bits); //< here bits &= m; } 

Test

int main() { std::bitset<64> b; b.flip(); apply_known_mask(b); std::cout << b.to_string() << '\n'; } 

Output

0000000000000000000000000000000000101110010000000000000100100100 // ^ ^^^ ^ ^ ^ ^ // O MLK H E D B 

one really has to appreciate C++`s ability to calculate anything turing computable at compile time. It surely still blows my mind (<>).


For the later versions C++14 and C++17 yakk's answer already wonderfully covers that.

2 Comments

How does this demonstrate that apply_known_mask actually optimizes?
@AlexReinking: All the scary bits are constexpr. And while that's theoretically not sufficient, we know that GCC is quite capable of evaluating constexpr as intended.
8

I would encourage you to write a proper EnumSet type.

Writing a basic EnumSet<E> in C++14 (onwards) based on std::uint64_t is trivial:

template <typename E> class EnumSet { public: constexpr EnumSet() = default; constexpr EnumSet(std::initializer_list<E> values) { for (auto e : values) { set(e); } } constexpr bool has(E e) const { return mData & mask(e); } constexpr EnumSet& set(E e) { mData |= mask(e); return *this; } constexpr EnumSet& unset(E e) { mData &= ~mask(e); return *this; } constexpr EnumSet& operator&=(const EnumSet& other) { mData &= other.mData; return *this; } constexpr EnumSet& operator|=(const EnumSet& other) { mData |= other.mData; return *this; } private: static constexpr std::uint64_t mask(E e) { return std::uint64_t(1) << e; } std::uint64_t mData = 0; }; 

This allows you to write simple code:

void apply_known_mask(EnumSet<Flags>& flags) { static constexpr EnumSet<Flags> IMPORTANT{ B, D, E, H, K, M, L, O }; flags &= IMPORTANT; } 

In C++11, it requires some convolutions, but remains possible nonetheless:

template <typename E> class EnumSet { public: template <E... Values> static constexpr EnumSet make() { return EnumSet(make_impl(Values...)); } constexpr EnumSet() = default; constexpr bool has(E e) const { return mData & mask(e); } void set(E e) { mData |= mask(e); } void unset(E e) { mData &= ~mask(e); } EnumSet& operator&=(const EnumSet& other) { mData &= other.mData; return *this; } EnumSet& operator|=(const EnumSet& other) { mData |= other.mData; return *this; } private: static constexpr std::uint64_t mask(E e) { return std::uint64_t(1) << e; } static constexpr std::uint64_t make_impl() { return 0; } template <typename... Tail> static constexpr std::uint64_t make_impl(E head, Tail... tail) { return mask(head) | make_impl(tail...); } explicit constexpr EnumSet(std::uint64_t data): mData(data) {} std::uint64_t mData = 0; }; 

And is invoked with:

void apply_known_mask(EnumSet<Flags>& flags) { static constexpr EnumSet<Flags> IMPORTANT = EnumSet<Flags>::make<B, D, E, H, K, M, L, O>(); flags &= IMPORTANT; } 

Even GCC trivially generates an and instruction at -O1 godbolt:

apply_known_mask(EnumSet<Flags>&): and QWORD PTR [rdi], 775946532 ret 

9 Comments

In c++11 much of your constexpr code isn't legal. I mean, some has 2 statements! (C++11 constexpr sucked)
@Yakk-AdamNevraumont: You did realize that I posted 2 versions of the code, the first for C++14 onward, and a second specially tailored for C++11? (to account for its limitations)
It might be better to use std::underlying_type instead of std::uint64_t.
@James: Actually, no. Do note that EnumSet<E> does not use a value of E as value directly, but instead uses 1 << e. It's a different domain altogether, which is actually what makes the class so valuable => no chance of accidentally indexing by e instead of 1 << e.
@MatthieuM. Yes you're right. I'm confusing it with our own implementation which is very similar to yours. The disadvantage of using (1 << e) is that if e is out of bounds for the underlying_type's size then it's probably UB, hopefully a compiler error.
|
7

Since C++11 you could also use classic TMP technique:

template<std::uint64_t Flag, std::uint64_t... Flags> struct bitmask { static constexpr std::uint64_t mask = bitmask<Flag>::value | bitmask<Flags...>::value; }; template<std::uint64_t Flag> struct bitmask<Flag> { static constexpr std::uint64_t value = (uint64_t)1 << Flag; }; void apply_known_mask(std::bitset<64> &bits) { constexpr auto mask = bitmask<B, D, E, H, K, M, L, O>::value; bits &= mask; } 

Link to Compiler Explorer: https://godbolt.org/z/Gk6KX1

The advantage of this approach over template constexpr function is that it's potentially slightly faster to compile due to rule of Chiel.

Comments

0

There are some far to 'clever' ideas here. You are probably not helping maintainability by following them.

is

{B, D, E, H, K, M, L, O}; 

so much easier to write than

(B| D| E| H| K| M| L| O); 

?

Then none of the rest of the code is needed.

3 Comments

"B", "D", etc are not flags themselves.
Yes, you would need to transform these to flags first. That's not at all clear in my answer. sorry. I will update.
It's not about easy to write. If that were true, we'd all write C. It's about type safety, compile-time checks, const-correctness, generics, and code reuse.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.