Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
andrewrk opened this issue Feb 9, 2018 · 11 comments
Labels
accepted This proposal is planned. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Feb 9, 2018

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

@andrewrk andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Feb 9, 2018
@andrewrk andrewrk added this to the 0.3.0 milestone Feb 9, 2018
@jfo
Copy link
Contributor

jfo commented Feb 9, 2018

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
Copy link
Member Author

andrewrk commented Feb 9, 2018

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
Copy link
Contributor

jfo commented Feb 9, 2018

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

@andrewrk andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018
andrewrk added a commit that referenced this issue Apr 15, 2018
@andrewrk andrewrk added contributor friendly This issue is limited in scope and/or knowledge of Zig internals. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. accepted This proposal is planned. and removed enhancement Solving this issue will likely involve adding new logic or components to the codebase. labels Nov 29, 2018
andrewrk added a commit that referenced this issue Dec 13, 2018
 * add `@bswap` builtin function. See #767
 * comptime evaluation facilities are improved to be able to
   handle a `@ptrCast` with a backing array.
 * `@truncate` allows "truncating" a u0 value to any integer
   type, and the result is always comptime known to be `0`.
 * when specifying pointer alignment in a type expression,
   the alignment value of pointers which do not have addresses
   at runtime is ignored, and always has the default/ABI alignment
 * threw in a fix to freebsd/x86_64.zig to update syntax from
   language changes
 * some improvements are pending #863

closes #638
closes #1733

std lib API changes
 * io.InStream().readIntNe renamed to readIntNative
 * io.InStream().readIntLe renamed to readIntLittle
 * io.InStream().readIntBe renamed to readIntBig
 * introduced io.InStream().readIntForeign
 * io.InStream().readInt has parameter order changed
 * io.InStream().readVarInt has parameter order changed
 * io.InStream().writeIntNe renamed to writeIntNative
 * introduced io.InStream().writeIntForeign
 * io.InStream().writeIntLe renamed to writeIntLittle
 * io.InStream().writeIntBe renamed to writeIntBig
 * io.InStream().writeInt has parameter order changed
 * mem.readInt has different parameters and semantics
 * introduced mem.readIntNative
 * introduced mem.readIntForeign
 * mem.readIntBE renamed to mem.readIntBig and different API
 * mem.readIntLE renamed to mem.readIntLittle and different API
 * introduced mem.readIntSliceNative
 * introduced mem.readIntSliceForeign
 * introduced mem.readIntSliceLittle
 * introduced mem.readIntSliceBig
 * introduced mem.readIntSlice
 * mem.writeInt has different parameters and semantics
 * introduced mem.writeIntNative
 * introduced mem.writeIntForeign
 * mem.writeIntBE renamed to mem.readIntBig and different semantics
 * mem.writeIntLE renamed to mem.readIntLittle and different semantics
 * introduced mem.writeIntSliceForeign
 * introduced mem.writeIntSliceNative
 * introduced mem.writeIntSliceBig
 * introduced mem.writeIntSliceLittle
 * introduced mem.writeIntSlice
 * removed mem.endianSwapIfLe
 * removed mem.endianSwapIfBe
 * removed mem.endianSwapIf
 * added mem.littleToNative
 * added mem.bigToNative
 * added mem.toNative
 * added mem.nativeTo
 * added mem.nativeToLittle
 * added mem.nativeToBig
andrewrk pushed a commit that referenced this issue Jan 2, 2019
* bitreverse - give bswap behavior

* bitreverse, comptime_ints, negative values still not working?

* bitreverse working for negative comptime ints

* Finished bitreverse test cases

* Undo exporting a bigint function. @bitreverse test name includes ampersand

* added docs entry for @bitreverse
@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Mar 22, 2019
@emekoi
Copy link
Contributor

emekoi commented May 27, 2019

Standard C Library Intrinsics

Bit Manipulation Intrinsics

@shawnl
Copy link
Contributor

shawnl commented Jun 19, 2019

This requires adding a libm implementation to zig,(which i started here #2709) as llvm generates libcalls to libm. Also, once this is complete, I want to move implementations into c.zig and libm.zig and then have the std library versions just call the intrinsics, so that llvm (or other frontends) can optimize these as is appropriate.

@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Sep 2, 2019
@Tetralux
Copy link
Contributor

Tetralux commented Sep 2, 2019

Does LLVM also have a pause intrinsic?
https://www.felixcloutier.com/x86/pause

Would this be considered to be added for this too, or should that be a seperate issue?

@shawnl
Copy link
Contributor

shawnl commented Sep 2, 2019 via email

@matu3ba
Copy link
Contributor

matu3ba commented Feb 9, 2023

semi-related to #1290, ie for powi

@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jun 29, 2023
@expikr
Copy link
Contributor

expikr commented Mar 15, 2024

semi-related:

sincos: #18527

rsqrt: #19302

fpatan: #19330

@achan1989
Copy link
Contributor

std/special/builtin.zig no longer exists. Can I get a summary of where the intrinsics are implemented, and how they are exposed as @ builtins?

@nektro
Copy link
Contributor

nektro commented Sep 23, 2024

mainly here
https://github.com/ziglang/zig/blob/master/lib/std/zig/BuiltinFn.zig
https://github.com/ziglang/zig/blob/master/lib/std/zig/Zir.zig#L133 (std.zig.Zir.Inst.Tag)
https://github.com/ziglang/zig/blob/master/src/Sema.zig#L1009 fn analyzeBodyInner
compile errors will guide you to everything else

@andrewrk andrewrk modified the milestones: 0.14.0, 0.15.0 Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. contributor friendly This issue is limited in scope and/or knowledge of Zig internals. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

9 participants