EgorBo
commented
1 week ago LICMing them into volatile registers feels fine.
My understanding that you can't use volatile registers here since you have a call in the loop, so you will have to do spill inside the loop.
This vector LICM seems like it is probably profitable - even with the stack spill - for more expensive vector operations. vpbroadcastb has extremely low latency/cost from what I know though, so in this case it's potentially worse.
Well, you're trading an instruction with Latency=3 (e.g. Tiger Lake) in a loop vs a single stack spill/reload, I am not so sure it's cheaper, especially, for a long-running loop. cc @dotnet/jit-contrib
PS: if you check codegen for Linux (SysV 64 ABI) it will emit what you expect due to lack of callee-saved float regs
AndyAyersMS
kg
JulieLeeMSFT
dotnet-policy-service[bot]
Description
If you have a loop that does
Vector128.Create(scalar)each iteration on purpose, RyuJIT can LICM the vector constant out of the loop. This sounds great in theory, but if you look at the generated code, this can move the cached vpbroadcastb result into xmm6 or a similar nonvolatile register, which can force your method to spill the previous value of xmm6 to the stack on entry and restore it on exit. In my real-world scenario, without this LICM the stack isn't used other than some regular register pushes at entry.Simple method calls or method-call-free loop bodies don't seem to trigger this, RyuJIT will happily use the volatile xmm registers instead and everything is good. An IEqualityComparer.Equals call inside the loop body is enough to force use of xmm6, though.
Reproduction Steps
This demonstrates the LICM in a toy scenario. For a real-world scenario, https://github.com/kg/SimdDictionary/blob/e42d42f7158d2552c97e1a517b82d4bb32750456/DisasmHarness/DisasmHarness.cs#L14 when disasmo'd will demonstrate it.
Expected behavior
Neither of the
vpbroadcastb's should be LICM'd out of the loop if they end up in a nonvolatile register IMO, since doing that forces a stack spill at entry and a stack restore at exit. LICMing them into volatile registers feels fine.Actual behavior
The provably-constant
vpbroadcastbis LICM'd out of the loop, which is correct but potentially deleterious for performanceRegression?
Don't know. Can't test since my real use case won't work on NET7.
Known Workarounds
EDIT: Changing the type of the
scalarparameter toin byteprevents the broadcast from being LICM'd. Putting a Thread.MemoryBarrier doesn't stop the broadcast from moving out of the loop (past the barrier), which is a little surprising, but probably completely safe. You can also block LICM by falsely taking the address of the local containing the scalar, i.e.EDIT 2: Inserting a
Sse2.MemoryFence()right before the broadcast operation stops it from being LICM'd, but it's pretty clear that it isn't a good solution.EDIT 3: A
Sse.Prefetch0(...)also works as a LICM barrier but seems to generate extra wasted code to calculate the address to prefetch for some reason.Configuration
Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.11.3
Other information
This vector LICM seems like it is probably profitable - even with the stack spill - for more expensive vector operations. vpbroadcastb has extremely low latency/cost from what I know though, so in this case it's potentially worse. The code I'm optimizing typically runs its loop body 0-1 times, so the LICM causes a performance hit.