Bug 50481 - builtin to reverse the bit order
Summary: builtin to reverse the bit order
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.7.0
: P3 enhancement
Target Milestone: ---
Assignee: Andrew Pinski
URL:
Keywords: missed-optimization
Depends on:
Blocks: 50160
  Show dependency treegraph
 
Reported: 2011-09-22 10:26 UTC by Marc Glisse
Modified: 2024-05-21 15:29 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-10-02 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Glisse 2011-09-22 10:26:07 UTC
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.
Comment 1 Jonathan Schmidt-Dominé 2011-09-23 15:30:33 UTC
Informative web-page listing some methods: http://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith64BitsDiv
Comment 2 Tim Parker 2012-03-29 10:46:11 UTC Comment hidden (spam)
Comment 3 Matthijs van Duin 2016-12-09 01:15:21 UTC
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! [1]

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 [2].

[1] https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01913.html
[2] http://clang.llvm.org/docs/LanguageExtensions.html#builtin-bitreverse
Comment 4 Trass3r 2018-11-08 10:00:56 UTC
+1
The builtins already produce better code than a generic bitreverse implementation:
https://godbolt.org/z/Um2Tit

But using special hardware instructions automatically is even more important imho.
Comment 5 Wilco 2019-06-20 15:55:16 UTC
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
Comment 6 Joseph S. Myers 2019-09-15 16:39:35 UTC
As noted in the RISC-V BoF today, this would also be useful for the RISC-V bit-manipulation extension.
Comment 7 Frank 2021-11-05 13:37:25 UTC
Would be really useful to have this.
Comment 8 Carlo Wood 2022-10-25 12:26:29 UTC
Bump - I need this too ;)
Comment 9 Xi Ruoyao 2023-10-02 11:17:25 UTC
Useful for LoongArch too.  And now we already have bitreverse RTX code since r14-1586.
Comment 10 Andrew Pinski 2024-05-21 15:22:14 UTC
I am going to implement this. and add an optab too.
Comment 11 Andrew Pinski 2024-05-21 15:24:38 UTC
The builtins I am going to implement to be similar to clang:
__builtin_bitreverse{8,16,32,64,g}

The g one is not part of clang but will be used for _BitInt types.
Comment 12 Andrew Pinski 2024-05-21 15:29:58 UTC
Also will add an internal function which will be used for vectorization.