Extra Bit Manipulation intrinsics?

Would it be worth it to add intrinsics for bitfield extract/deposit and binary rotate left/right?
Both of these have dedicated instructions in multiple ISAs, including the two major ISAs (x86-64 and ARM)
Adding them could decrease load on the backend to recognize common intrinsic patterns that correspond to these instructions, but could increase load on backends that do not have dedicated instructions for these intrinsics.

There used to be such intrinsics (bit-field extract/deposit):



But they are removed later.

Our internal branch of llvm actual keep them.
Depending on how you want to use them, if you mixed them into pointer calculations, it can easily confuse scalar evolution. This is bad.
Also, it is not hard to build these intrinsics from patterns of and/or/shift/trunc/zext, so mabe you could build them in the backend instead of at the LLVM IR level. E.g https://github.com/etherzhhb/Shang/blob/eb4aa11385b93af4b73cfd4701e1473124ada325/lib/BitLevelOpt/BitLevelOpt.cpp

The problem with that is that a bitfield extract of n bits starting at bit b (mask == (1<<b)-1) corresponds to:

   (X >> b) & mask

Replacing it with an intrinsic hides this fact and you have to carefully examine every instcombine rule that operates on an “&” to also operate on the bitfield extract. You need to add a good amount of extra combines and it becomes likely that some get missed. Thus forming such intrinsics before instruction selection in the backend is bad from a software engineering point of view IMO.

A similar reasoning can be applied to bitfield insertions.

- Matthias

Rotates are a special case of the recently added funnel shift ops:

We don’t canonicalize standard IR (shifts and bitwise logic) to the intrinsics yet, but that is the intent.

There are also clang builtins for rotate left/right that map to the funnel shift intrinsics: