Adding bit manipulation intrinsics:

[gnzlbg]

I could add the bit manipulation intrinsics from the bitintr library to this one. I have two questions:

• IIUC the intrinsics here should be marked with #[target_feature] and be unsafe, that is, they are guaranteed to generate the right CPU instructions on the targets that support a feature. Portability is left to third-party crates, is this correct?
• Given the organization in this crate, I would be adding the following modules (do they make sense?):
  • x86::{bmi1, bmi2, abm, tbm}
  • arm::{v5, v6, v7, v8}
• Should the crate be renamed to something else?

[BurntSushi]

Should the crate be renamed to something else?

I commented on that here: #11 (comment)

Given the organization in this crate, I would be adding the following modules (do they make sense?):

Yeah that layout seems fine. Note that I only have x86 so far, and I don't have a good process for testing other platforms yet. I'm tracking that in #13.

IIUC the intrinsics here should be marked with #[target_feature] and be unsafe, that is, they are guaranteed to generate the right CPU instructions on the targets that support a feature. Portability is left to third-party crates, is this correct?

We did land on unsafe then? I just forgot. Yeah that probably means all of the vendor intrinsics need to be transitioned to unsafe as well, but you don't have to do that. I'm tracking that in #21.

But yes, otherwise, portability is left to other crates for now.

[alexcrichton]

@gnzlbg is this issue mostly done now?

[gnzlbg]

Yes, this is finished.