Re: Internal unwinding clobbers non-volatile registers.
- From: Can Boluk <can.boluk89@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 31 May 2021 13:55:53 +0200
[In other words: the MS ABI is problematic. It's the root cause
for most of the trouble when mixing AVX and SSE code, e.g. the
annoying VZEROUPPER instruction.]
I'm using a slightly modified version of the MS calling convention that
pretty much replaces xmm's with ymm's in this OS since I compile everything
with +avx2 so I went ahead and disabled the vzeroupper insertion pass in
LLVM, still have to finalize my upgrades to the lj_vm for VEX encoding of
XMMs to avoid the switch penalty when interacting with LuaJIT though haha.
The actual problem you'll eventually run into on such a platform,
is that only external unwinding is able to catch on-trace errors.
So far, this was mostly about catching out-of-memory errors, which
are fatal in most environments, anyway. But some future APIs, e.g.
the fast serializer, which is part of the new string buffer library,
will often be combined with pcall and need on-trace error handling.
I'll look into coming up with an external unwinding solution, relying on
INT alone indeed doesn't seem to be neither a fail-safe nor an efficient
solution.
Thanks for the tips,
Can
On Mon, May 31, 2021 at 11:57 AM Mike Pall <mikelj-2105@xxxxxxx> wrote:
Can Boluk wrote:
Does this behave as it should for non-MS x64 ABIs, System V for instance?
[...] ymm8-ymm15 [...]
Yes, because most registers are not saved in this ABI. And ymms
follow suit with xmms.
[In other words: the MS ABI is problematic. It's the root cause
for most of the trouble when mixing AVX and SSE code, e.g. the
annoying VZEROUPPER instruction.]
I'm using LuaJIT in a custom baremetal Ring0 environment so I'm by no
means
restricted to MS ABI, it's mainly that I cannot use external unwinding
since I don't have unwind tables [...]
Well, you could certainly generate those. I think it's more an
issue with supplying a working unwinder that handles them.
[
The actual problem you'll eventually run into on such a platform,
is that only external unwinding is able to catch on-trace errors.
So far, this was mostly about catching out-of-memory errors, which
are fatal in most environments, anyway. But some future APIs, e.g.
the fast serializer, which is part of the new string buffer library,
will often be combined with pcall and need on-trace error handling.
]
--Mike
Other related posts:
