These can be optimized into SIMD operations in some cases
4301cc2...
by
Andrei Alexeyev <email address hidden>
build,util/float16: add conversion routines between float32 and float16
Tries to use the compiler's native float16 type, such as _Float16 or
__fp16 first. This is the best case, because these conversions can
compile to single asm instructions on supported architectures, falling
back to calling a generic routine from the runtime library (libgcc or
compiler-rt).
Failing that, we'll try to call the rt library routines directly. This
is tricky, because there are no headers for those, and we must get the
ABI right. We must compile and run some code to detect the ABI, which is
not always possible when cross-compiling. For that reason, you can set
the `float16_rt_abi` property to either `native`, `integer`, or `none`
in the cross file.
The `native` ABI assumes that float16s are passed as the compiler's
_Float16 type (e.g. in xmm registers on x86_64). This is currently not
very useful, since on compilers that have _Float16 we'll simply use the
intrinsic conversions.
The `integer` ABI assumes that float16s are passed as uint16_t.
`none` means that no attempt to use the runtime library routines will be
made, even if they exist.
If we can use neither intrinsic conversions nor the runtime library,
we'll fall back to questionable bit hackery. This method currently does
not support infinities and NaNs.
528aec0...
by
Andrei Alexeyev <email address hidden>
hashtable: add strset to predefs
d32e53c...
by
Andrei Alexeyev <email address hidden>
dynarray: add macros for reverse iteration
0d3c2c1...
by
Andrei Alexeyev <email address hidden>
util/strbuf: fix strbuf_ncat()
b697817...
by
Andrei Alexeyev <email address hidden>
memory: use custom memory allocation wrappers
Introduces wrappers around memory allocation functions in `memory.h`
that should be used instead of the standard C ones.
These never return NULL and, with the exception of `mem_realloc()`,
zero-initialize the allocated memory like `calloc()` does.
All allocations made with the memory.h API must be deallocated with
`mem_free()`. Although standard `free()` will work on some platforms,
it's not portable (currently it won't work on Windows). Likewise,
`mem_free()` must not be used to free foreign allocations.
The standard C allocation functions are now diagnosed as deprecated.
They are, however, available with the `libc_` prefix in case interfacing
with foreign APIs is required. So far they are only used to implement
`memory.h`.
Perhaps the most important change is the introduction of the `ALLOC()`,
`ALLOC_ARRAY()`, and `ALLOC_FLEX()` macros. They take a type as a
parameter, and allocate enough memory with the correct alignment for
that type. That includes overaligned types as well. In most
circumstances you should prefer to use these macros. See the `memory.h`
header for some usage examples.
