Found an application today (hashtree tests) that causes us to spill a
large amount of values on to the stack.
We were encoding larger offsets than what unsigned offset load and store
can handle.
If the offset is too large for the loadstore, use a temporary to put the
offset in to first.
Previously this could access more elements than it needs to.
In the case where we pass in a 128-bit vector and perform a 128-bit
operation, only two doubles should be handled, but in this case will
actually try and handle four double elements.
Consider converting doubles within a vector into floats:
e.g. _Vector_FToF(16, 4, Src, 8)
16 is our OpSize
4 is our DestElementSize
Src is our input vector
8 is the SrcElementSize
(OpSize << 1) / Op->SrcElementSize becomes:
(16 << 1) / 8 ->
32 / 8 ->
4
What we actually want it 2 here, we're indexing 128-bit vectors out of
its bounds (not a problem now, since we assume up to 256-bit in the
interpreter).
Similarly with 256-bit vectors
_Vector_FToF(32, 4, Src, 8)
would become:
64 / 8 -> 8
where we actually want 4, since we only have 4 64-bit elements in a
256-bit vector.
This corrects this in the interpreter by just special-casing the 64-bit
calculation.
We generate a /lot/ of block links which causes our shutdown time to
take a while for this map. For short running applications this shutdown
time can take a statistically significant amount of time, and this has
been haunting us for a while.
Using a monotonic buffer resource, we can cut the dellocation time down
to effectively zero on cache clear and shutdown.
For short running applications this basically means we clear their
shutdown time, for long running applications this means a cache clear is
less painful.
I've measured up to 2ms , but more often this takes ~0.5ms before
optimization. Now it is consistently ~0.25ms on a short running
application.
Times will vary /greatly/ depending on how full it has filled this map.
CallumDev