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?  



On Mon, Mar 24, 2014 at 12:36 AM, Paul Khuong <pvk@pvk.ca> wrote:
Douglas Katzman wrote:
Anyone feeling particularly sentimental about the homebrew bzero for x86-64?
Or conversely, particularly antagonistic (Martin?)
[...]

I'd like to just remove the hand-written code rather than '#if' for
known good C libraries.

I'd just make sure that we save all XMM state before entering the runtime (e.g., when leaving PA or allocating memory). Detecting this class of bug after the fact is pretty painful. I believe we fixed some case on windows, but I'm not sure we covered all our bases.

Paul Khuong