05:35 <HdkR> Is SVE VL part of the ABI? wondering if it ends up changing depending on library usage

19:11 <broonie> HdkR: The ABI is VL agnostic.

19:13 <broonie> You're not supposed to change VL after thread startup, though there's nothing stopping you - if you do anything else which has stored SVE state is going to get upset. The standard ABI is that none of the SVE state is valid after a function call - there is also a SVE specific calling convention.

19:13 <HdkR> I see

19:14 <broonie> Anything that does use SVE will need to check the VL when allocating storage (there's a RDVL instruction for this), otherwise you should pretty much be able to ignore the VL in code.

19:16 <HdkR> I guess I'll need to burn some predicate registers for 128-bit and 256-bit wide or call arch_prctl after leaving the JIT space and coming back

19:18 <HdkR> Does VL change when a fault occurs or does it stay the same for when userspace catches it?

19:22 <broonie> I'm missing some context here...

19:23 <broonie> The VL will be the same in a signal handler as it is outside a signal handler, and we don't currently support changing VL through signal return.

19:24 <HdkR> alright, good to know. Concern was knowing current VL through a fault. If it had reset to 512bit but originally was 256-bit it could have been a concern

19:25 <broonie> The VL is part of the signal context so if you're in a signal handler looking at the signal frame you can look at that.

19:25 <broonie> If you return from a signal handler the SVE state should be restored identically unless the signal handler fiddles with the signal frame.

19:26 <HdkR> Good to know that VL is in it. Guess it is necessary for not consuming unnecessary stack space if VL is smaller than hardware max?

19:26 <HdkR> Since I'll be using it for the same purpose

19:27 <broonie> For SME when you get to having an implementation of that available we exit streaming mode when taking a signal but otherwise everything works the same (SM is part of the signal context so will be restored whne returning from the signal handler).

19:28 <broonie> The VL is in there since ideally we should support changing the VL through signal return - in theory this is something something using userspace threads done via sigreturn could use if threads have different VLs. I don't know why this wasn't supported when SVE was merged TBH.

19:30 <broonie> In practice it's unclear if people are likely to have threads with different VLs in the same process.

19:31 <HdkR> I'll definitely be doing that

19:31 <broonie> Mixing VLs? What's the use case OOI?

19:33 <HdkR> Primary threads will be limiting themselves to 128-bit or 256-bit *depending* and then tertiary threads will just be running at max length

19:33 <broonie> I'm still missing context here - what are you implementing here?

19:34 <broonie> And what's a primary/tertiary thread?

19:35 <HdkR> This is just an x86 emulator implementing AVX using SVE. Helping threads don't need to limit their vector length

19:36 <broonie> Ah, so you're matching the VL to the VL of the thing you're emulating?

19:36 <HdkR> aye

19:36 <broonie> Right, that makes total sense.

19:37 <broonie> And are you using lightweight threads for this (ie, changing "thread" via sigreturn)?

19:38 <HdkR> nah, using real threads. Just have a concern if any host library changes VL

19:39 <broonie> I'd be really surprised if anything does that without restoring before return, it'll cause all kinds of breakage if things are using SVE.

19:40 <HdkR> You never know what libGL/libVulkan and other "high-performance" things end up doing :P

19:41 <broonie> changing VL is at a minimum a syscall, and will trigger a full discard of SVE state and backing storage plus a trap to reallocate which should discourage doing anything clever in calling context.

19:42 <broonie> You'd be more likely to create a worker thread and set the VL you wanted in there.

19:45 <HdkR> Indeed. I'll be setting the VL on thread start where it is expected. But since it isn't a full system VM I can't quite control the world. Need to hope libraries don't pull the rug out from under me

19:46 <HdkR> userspace syscall dispatch would likely let me capture anything trying to do this. Once that feature is available anyway

20:02 <broonie> Like I say that's a totally reasonable expectation for libraries, anything that fiddles with the VL without coordinating with the rest of the thread is going to break things.

20:12 <HdkR> I'll move forward with the expectation that libraries won't heck with VL. Then I can handle the pain once/if it happens.