Implement support for rotate.

[mbodart]

Of the integer operations listed in FutureFeatures.md, it seems that bswap and the rotates fall into the camp of popcnt, clz and ctz, in that they are directly supported by current architectures.

This change implements i32 and i64 bswap, rol and ror, along with test cases.

I just noticed a minor name difference, where FutureFeatures.md uses rotl and rotr,
while I used rol and ror. I have no strong preference either way.

Of course, we need agreement as to whether this support is desired.
I'm about to raise this as an issue, and am submitting this PR in support.

[jfbastien]

(Confirming that @mbodart is part of the CG, representing Intel).

[qwertie]

+1 from me... I always wanted a VM with the same basic abilities as my own CPU.

[sunfishcode]

The corresponding design PR is now merged: WebAssembly/design#462. This PR lgtm, though it just needs a merge conflict resolution.

[mbodart]

Just updated ... should be good to go.

Thanks!

[sunfishcode]

lgtm. thanks!

[ghost]

@mbodart Could you try git fetch upstream git checkout master git merge upstream/master git checkout bswaprotate git rebase master to clear up the patch. Perhaps also git rebase -i master and squash it into one patch.

[mbodart]

Sorry, I'm a relative newbie wrt git, and was just following a pattern in the Pro Git book.
For my education, how is the patch messed up?
Do I need to ensure my fork's master branch has been merged with upstream (and pushed?)
prior to pushing a topic branch update?

Following your instructions, the "git rebase master" needs the same conflict resolution as
my recent update. Will that be problematic?

Please advise, thanks.

[ghost]

@mbodart I'm no git expert, but the patch mbodart@863f4d4 does not look clean. Github seems to think it's ok to merge, so perhaps it is and @sunfishcode gave it lgtm just as I was posting.

My understand is the conflicts need to be resolved, edit the file, then git add <file> git rebase --continue. When done recheck the patch. Sorry if this is all just noise.

[mbodart]

I resolved the conflicts when merging with my local bswaprotate branch.
Perhaps the confusion here is that I left the "Conflicts" file list in the commit message.
I did so just as a reminder that there were conflicts in the merge, albeit resolved.

Thanks for being diligent, but I think we're all set.

[kripken]

I still see a merge commit in the 3 commits here. It would be nicer to avoid that. You should be able to just do git rebase upstream/master (assuming this repo is called "upstream" in your git remotes) to fix that, and then just push it to your branch (you'll need git push -f [..], a force-push, since the rebase will mean they can't be fast-forwarded).

[mbodart]

One more try, hope this works.
I sync'd my fork's master with the spec, then rebased bswaprotate off of my local master.
This seems to have eliminated the merge commit, though there are still two commits.

[kripken]

If we also want to squash those two commits, rebase -i upstream/master and then putting "s" for squash for the second commit, should do it. But I'm not sure if people prefer it squashed or if there is useful history in the separation.

[rossberg]

LGTM, but please make sure to update the description, since this patch no longer contains byteswap.