add a builtin function for every llvm C library intrinsic and bit manipulation instrinsics

[andrewrk]

http://llvm.org/docs/LangRef.html#standard-c-library-intrinsics
http://llvm.org/docs/LangRef.html#bit-manipulation-intrinsics

LLVM has these because

• they can sometimes map to hardware instructions (such as sqrt) (see Add hw sqrt for x86_64 #681)
• LLVM codegen assumes that it can call these functions, which is why we have to provide compiler_rt.o
• additional optimization awareness and integration with fast-math

This issue is to

• implement all the intrinsics in std/special/builtin.zig
• add all the intrinsics as @ builtin functions in zig
• most std.math.* functions can just call out to the builtin functions

related: #514

[jfo]

I like the idea of std library functions calling directly into intrinsics when possible, but that makes me wonder why the intrinsic would be available to user space at all, or at least why it would look the same as the other built-ins.

The number of potential @ functions is quite large, but there is no native name spacing scheme right now for keeping them grouped logically. Would that be something worth considering?

[andrewrk]

I like the idea of std library functions calling directly into intrinsics when possible, but that makes me wonder why the intrinsic would be available to user space at all, or at least why it would look the same as the other built-ins.

The standard library is user space. The other built-ins are very similar. These are no different than @ctz, @clz, @memset, @memcpy, @fence, @addWithOverflow, etc.

The number of potential @ functions is quite large, but there is no native name spacing scheme right now for keeping them grouped logically. Would that be something worth considering?

It's not that large. We're talking about adding 25 functions, and there are no name collisions, and we already use @ to prevent collisions with user space functions.

[jfo]

Fair enough, but at the least it would help to group them in the documentation at some point, I think.