It would be useful if gcc provided a builtin to reverse the order of the bits (turn abcdefgh into hgfedcba) in objects of all sizes from a byte to an unsigned long long.
According to Joseph: "Various processors have an instruction to reverse the bit order in a word (ARMv6T2 and later have RBIT, for example, and C6X has BITR on C64X and above)." This kind of bit manipulation also has various optimizations depending on the architecture (mirroring a byte can be implemented using a 64bit multiplication). It is thus well suited to a builtin with different platform-specific implementations.
Such a builtin could be used for instance for Bug 50160.
Informative web-page listing some methods: http://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith64BitsDiv
I totally don't understand what you talking about =_=
Bump! Proper intrinsics for bitreverse would be much appreciated! A plain C implementation is ugly and results in equally awful code output, while using inline asm breaks portability and can't be constant-folded or used in constexpr.
What makes the continued lack of a __builtin_arm_rbit() in gcc a bit bizarre is that the (identically named) Neon versions of this instruction on AArch64 actually *did* receive proper intrinsics! 
It's worth mentioning that clang does support __builtin_arm_rbit(), and they've actually generalized this to a full set of target-independent bitreverse builtins .
The builtins already produce better code than a generic bitreverse implementation:
But using special hardware instructions automatically is even more important imho.
Yes it would be good to have a generic builtin, this issue keeps coming up: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01187.html
As noted in the RISC-V BoF today, this would also be useful for the RISC-V bit-manipulation extension.