compiler: implement most math/bits functions

[aykevl]

These functions can be implemented more efficiently using LLVM intrinsics (at the moment, they're implemented as regular Go code). That makes them the Go equivalent of functions like __builtin_clz which are also implemented using these LLVM intrinsics.

I believe the Go compiler does something very similar: IIRC it converts calls to these functions into optimal instructions for the given architecture.

I tested these by running tinygo test math/bits after uncommenting commenting the tests that would always fail (the *PanicZero and *PanicOverflow tests). We should either implement -test.skip or the ability to catch runtime panics to be able to test this automatically.

EDIT: s/uncommenting/commenting

[dgryski]

My only concern is that the llvm versions are "slightly" different from the Go versions. But I suppose running the tests with all their edge cases probably verifies that they're not.

[dgryski]

LGTM

[dgryski]

My only concern is that the llvm versions are "slightly" different from the Go versions. But I suppose running the tests with all their edge cases probably verifies that they're not.

[deadprogram]

Thanks @aykevl for the maths bits 😺

[aykevl]

My only concern is that the llvm versions are "slightly" different from the Go versions. But I suppose running the tests with all their edge cases probably verifies that they're not.

In what way are they different? They should have identical behavior the way I implemented it, or did I miss something?

For example, here is OnesCount32:

OnesCount32 returns the number of one bits ("population count") in x.

And here is the LLVM version:

The ‘llvm.ctpop’ family of intrinsics counts the number of bits set in a value.

To me, that's exactly the same thing.

[dgryski]

Oops, that was poor writing on my part. "My only concern would be if the two versions are slightly different." But it turns out they're not and running all the tests shows that to be the case.

[aykevl]

Ah I see. Yes, the tests all pass which is good. (Which is also a reason to not replace the package entirely: this way, we keep all existing tests).