Are you suggesting that fast_bzero should be a wrapper that saves all xmm state, calls bzero, restores xmm state?
This seems like terrible abstraction breakage if 'fast_bzero' was not "merely" a drop-in replacement but is in fact something like that wrapper plus a reimplementation of the underlying thing.
But to reason this through:
- a thread that got into GC by way of 'alloc_tramp' has already saved xmm state before calling C to perform the alloc().
- a thread which reaches SUB-GC by voluntary action, which includes leaving a without-gcing section, is making an ordinary call into an ordinary Lisp function, and so we assume callee-saves-nothing anyway.
Where is a kind of place at which state would get trashed?