Re: freeze for sbcl-2.6.8

The normal case can be made to just save XMMs, and the avx saver could
have a parameter for ymm/zmm. And instead of looking at the whole
component for ymm/zmm users it should check if they are actually alive
at the point of a tramp call.

On Sat, Aug 22, 2026 at 7:14 PM Stas Boukarev <[email protected]> wrote:
>
> Sure, vmovaps might be faster in that place, but then everything will
> be tainted by touching the high bits of ymm, and any use of sse2 will
> transition back-and-forth between states, killing performance. Hence
> why it uses xsave in the first place.
> Saving ymm might work if it does the same thing as is currently done
> for avx512, i.e. not touching them until used. But there's a lot of
> routine explosions because of that (might also avoid saving xmm),
> maybe some parameters instead of dedicated entry points.
>
> As for the patch, it's hard for me to review it, lots of matching
> between things to perform, but I suppose if it runs, it's hard to go
> far with this stuff being wrong.
> I don't lean one way or another on when to commit it.
>
> On Sat, Aug 22, 2026 at 7:07 PM Douglas Katzman <[email protected]> wrote:
> >
> > I have the fix for that crash.   I mistakenly thought that FPR-SAVE/FPR-RESTORE no longer need to preserve RDX when using XRSTOR but they still do - but only for #+win32, so I'll add that.
> > However, Gemini claims the following theoretical performance gain by simply avoiding XSAVE/XRSTOR entirely in the YMM case (not the avx512 of course) which is a very interesting point -
> >
> > ~4x Faster: 16 * VMOVAPS runs in ~15–20 cycles vs 80+ cycles for XSAVE/XRSTOR.
> >
> > Do you think I can commit this register changing patch + its fix for now, and we'll leave the above suggestion for next release (despite also being a valid fix for my crash) ?


_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel