Rename rdrnd target feature to rdrand

[newpavlov]

Plus minor cleanup.

Related stdsimd issue.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[nikomatsakis]

Typo: s/aplpying/applying

[nikomatsakis]

r? @nagisa =)

[nikomatsakis]

cc @alexcrichton @BurntSushi

[BurntSushi]

This seems right to me, and is what Intel refers to upstream. Do we know why LLVM calls this rdrnd?

[nagisa]

Looking at the blame, it seems that rdrnd was chosen to match what gcc and clang "use" (before 2013 the feature was named rdrand). Clang probably copied the name from GCC and it is probable that GCC implemented this feature before the RDRAND name was widespread/confirmed/etc.

[nagisa]

This is the commit.

[BurntSushi]

Ug, so you're saying other compiler front ends use rdrnd instead of rdrand? To me, that makes this a harder decision. So I think our choices are:

1. Conform with what people expect using other popular compilers. (Accept only rdrnd.)
2. Conform with upstream vendors. (Accept on rdrand.)
3. Conform to both. (Accept rdrnd or rdrand as aliases of one another.)

I'm not really a fan of any of these, but I feel myself leaning toward (1).

[newpavlov]

@alexcrichton opinion was to follow vendor names.

[nagisa]

@newpavlov that was an opinion in context of llvm vs vendor and not gcc/clang vs vendor, though.

I can say for sure that I was super surprised that +rdrand didn’t work and took me a while to figure out that it is in fact +rdrnd, so I’m certainly in favour of this change.

[newpavlov]

@nagisa
I believe pclmul was chosen by LLVM over pclmulqdq for the same reasons as rdrnd over rdrand. In other words "lvm vs vendor" looks like is equivalent to "gcc/clang vs vendor", as clang follows gcc and in turn LLVM follows clang.

[nagisa]

@bors r+

[bors]

📌 Commit a33c1da has been approved by nagisa

[BurntSushi]

I'm still not convinced that this is the right path to take. Being different from the vendor stinks, but being different from other mainstream compiler front ends also stinks (which is very different from eschewing LLVM names specifically, which I'd be totally fine with). I didn't see any consideration given to supporting both?

[nagisa]

@BurntSushi well, it is something relevant to more than just rdrand, and is something we should decide about in context of all features. If we decide to have aliases for compatibility with other compilers, we can simply add the cases for all the features at the same time.