Imlement rdrand and rdseed intrinsics

[newpavlov]

• _rdrand16_step
• _rdrand32_step
• _rdrand64_step
• _rdseed16_step
• _rdseed32_step
• _rdseed64_step

It will require addition of two target features rdrand and rdseed to the language.

cc @nagisa

[newpavlov]

I don't quite get how to link to the LLVM intrinsic llvm.x86.rdrand.64, IUUC correctly it has two return values i64 and i32. All options which I've tried result in "Intrinsic has incorrect return type!". Can someone help with it?

[nagisa]

You cannot link to this intrinsic this way, because it returns {i1, i<width>}, which is not expressible in a stable manner (there's no guarantee that any rust type will lower down into that particular LLVM type).

…

On Feb 19, 2018 01:10, "Artyom Pavlov" ***@***.***> wrote: I don't quite get how to link to the LLVM intrinsic llvm.x86.rdrand.64, IUUC correctly it has two return values i64 and i32. All options which I've tried result in "Intrinsic has incorrect return type!". Can someone help with it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#325 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0oLMPYmMjtO3qBZQ0DeIzwVaoQ9-ks5tWK39gaJpZM4SJsfv> .

[nagisa]

I misremembered. The type is {I<width>, i32} but the general point about it not being expressible stands.

…

On Feb 19, 2018 07:49, "Simonas Kazlauskas" ***@***.***> wrote: You cannot link to this intrinsic this way, because it returns {i1, i<width>}, which is not expressible in a stable manner (there's no guarantee that any rust type will lower down into that particular LLVM type). On Feb 19, 2018 01:10, "Artyom Pavlov" ***@***.***> wrote: > I don't quite get how to link to the LLVM intrinsic llvm.x86.rdrand.64, > IUUC correctly it has two return values i64 and i32. All options which > I've tried result in "Intrinsic has incorrect return type!". Can someone > help with it? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#325 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AApc0oLMPYmMjtO3qBZQ0DeIzwVaoQ9-ks5tWK39gaJpZM4SJsfv> > . >

[alexcrichton]

@newpavlov I think it's ok to use a asm! block temporarily for this, but yeah as @nagisa mentioned we'll need to add a dedicated intrinsic to rustc for this otherwise to get the ABI to work.

[nagisa]

rustc has the dedicated intrinsic. It is used by the rdrand crate.

…

On Feb 20, 2018 03:10, "Alex Crichton" ***@***.***> wrote: @newpavlov <https://github.com/newpavlov> I think it's ok to use a asm! block temporarily for this, but yeah as @nagisa <https://github.com/nagisa> mentioned we'll need to add a dedicated intrinsic to rustc for this otherwise to get the ABI to work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#325 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0rbh2ZTcbUqS9gEcqps5Bf-WYDreks5tWht-gaJpZM4SJsfv> .

[newpavlov]

@alexcrichton
Rust already supports rdrnd and rdseed features. But rdrnd is a LLVM feature name, while with pclmulqdq it was decided to use vendor name. What do you think about renaming this feature to rdrand for consistency? Will this change be backwards compatible? We can proabably support both rdrand and rdrnd for the time being, and deprecate rdrnd in the next epoch. This questions was earlier raised by @nagisa, but it was left unanswered.

[nagisa]

The change wouldn’t be backwards compatible, but since anything related to it is unstable in the first place, I do not see any reason to do the epoch dance.

[newpavlov]

@alexcrichton
Do we have to follow Intel intrinsics 1-to-1? It feels weird to have signature _rdrand64_step(val: &mut u64) -> i32 more natural for Rust will be _rdrand64_step() -> (u64, bool) or even _rdrand64_step() -> Option<u64>, plus it's closer to how instruction works. At least we could go with LLVM variant _rdrand64_step() -> (u64, i32).

[gnzlbg]

Do we have to follow Intel intrinsics 1-to-1?

Yep :/

It feels weird to have signature _rdrand64_step(val: &mut u64) -> i32 more natural for Rust will be _rdrand64_step() -> (u64, bool) or even _rdrand64_step() -> Option, plus it's closer to how instruction works. At least we could go with LLVM variant _rdrand64_step() -> (u64, i32).

You can build those in a wrapper outside stdsimd.

[gnzlbg]

@newpavlov FWIW I have such a wrapper here: https://github.com/gnzlbg/typed_arch