The check seems to have been assuming that rune comparisons are
unsigned, but they're signed. This was causing an assertion failure for
certain input characters (anything with an ASCII value less than
'+'/43).
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction in different orders than sequential order. These alternative
orders can often offer better SIMD hardware utilization.
Two different orders are added: pair-wise (operating on pairs of
adjacent elements) or bisection-wise (operating element-wise on the
first and last N/2 elements of the vector).
The indices proc simply creates a vector where each lane contains its
own lane index. This can be useful for use in generating masks for loads
and stores at the beginning/end of slices, among other things.
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction, in different orders than just "in sequential order". These
alternative orders can often be faster to calculate, as they can offer
better SIMD hardware utilization.
Two different orders are added for these: pair-wise (operating on
adjacent pairs of elements) or split-wise (operating element-wise on the
two halves of the vector).
This doesn't actually cover the *fastest* way for arbitrarily-sized
vectors. That would be an ordered reduction across the native vector
width, then reducing the resulting vector to a scalar in an appropriate
parallel fashion. I'd created an implementation of that, but it required
multiple procs and a fair bit more trickery than I was comfortable with
submitting to `core`, so it's not included yet. Maybe in the future.
The initial allocation for the slice is limited to prevent untrusted
data from forcing a huge allocation, but then the dynamic array was
created with a capacity of the unlimited length, rather than the actual
capacity of the allocation. This was causing a buffer overrun.
This can be important if matrices or SIMD vectors are being used in
global or static variables, as otherwise it may result in crashes due to
aligned instructions accessing misaligned variables.
The lower bound of the `bit_set` was only being applied *after*
searching for a matching enum value, so values wouldn't line up if the
minimum value of the enum wasn't 0.
The existing `mem.make_map` passes a capacity, but the builtin
`make_map` no longer takes a capacity--it was separated to
`make_map_cap` to allow for making a map without an allocation (#4340).
`core:mem` was not updated to reflect this, so any usage of `mem.make`
to make a map will currently result in a compile error.
Comparing SIMD vectors with `==` was checking that the mask of elements
that matched was not 0, meaning it succeeded if *any* element was equal,
rather than if *all* elements were equal.
This allows `*` to be used in C fashion, without specifying an argument
index to use. Like C, this results in the argument *preceding* the value
for the format specifier itself.
This affects `runtime.Arena` and `virtual.Arena`, but not currently
`mem.Arena`. These changes allow the last allocation that has been
made to be resized to a larger size by just extending their
allocation in-place, when there's sufficient room in the memory block to
do so.
Shrinking in place and re-using the rest of the allocation can be
supported using almost the same logic, but would require the memory to
be zeroed. Since this would add a additional cost that isn't currently
present, shrinking has not been changed.
Translation matrices use the w components of the matrix to apply the
transform, and thus only work when the w component is 1. In the
original raymath implementation, the multiplication is done manually
and adds the translation components directly to the result, as if w is
1, but in the Odin binding this is done with a matrix multiplication.
However, the w component is set to 0 instead of 1, resulting in the
translation not being applied.
Translation matrices use the w components of the matrix to apply the
transform, and thus only work when the w component is 1. In the
original raymath implementation, the multiplication is done manually
and adds the translation components directly to the result, as if w is
1, but in the Odin binding this is done with a matrix multiplication.
However, the w component is set to 0 instead of 1, resulting in the
translation not being applied.
Removed underscores from the AVX-512 names in `CPU_Feature` to make them match their equivalent LLVM target features. Removed 4FMAPs and 4VNNIW as there aren't matching LLVM target features.
Barinzaya
