With multiblock and -n4000, at least one block in geekbench5's camera
benchmark was spilling 324 values. This meant the required stack
adjustment was 5184 bytes, which is larger than can fit into a 12bit
immediate.
Now, it's probally a bug that our RA is spilling that many values, and
we probally should be packing our spill slots closer together, but we
still shouldn't fail to run in this edge case.
So this commit adds a fallback path which uses a temp register to load
the stack adjustment.
This is what shows up in /proc/cpuinfo
example on tagged release: 'model name : FEX-2101'
example on untagged release: 'model name : FEX-2101-64-g536be23f'
Fixes#661
Assembler by default doesn't allow you to use the assembler. Needs a
CodeBufferCheckScope.
Labels with binds and not links will throw an assert.
ExitSpillSRA was using b instead of bind incorrectly.
Thus branching to a invalid location
cmpxchg/cmpxchg8b doesn't have alignment requirements on x86, which means
applications rely on unaligned behaviour support with it.
Steam relies on this to work for a linked list array of jobs in some
internal job queueing system. It will end up always aligning by offsets
of 4 since it stores a couple of pointers.
Doesn't currently support the case of unaligned cmpxchg8b crossing a
cacheline, which ends up being semi-broken depending on which x86
behaviour the application is expected.
Intel CPUs do the "Big ring lock" or "split locks". Which means accesses
across cachelines are atomic.
AMD CPUs will tear the value across the cacheline, which is expected x86
behaviour by spec.
If they are expecting Intel behaviour, then that application is just
broken on non-Intel platforms unless they are fine with a tear.
In the case of an instruction that used 16bit addressing mode. It would
calculate the amount of displacement needing to be read using a 32bit
modrm mode. It would then read calculate modrm displacement again and
read the correct number of bytes.
Leftover bytes would then be in a mismatched state which means if an
instruction was using 16bit addressing + modrm + literal at /that/ point
the number of literal bytes remaining would be calculated as a negative.
This didn't actually break things since instructions that have modrm +
literal and can safely use 16bit addressing without breaking in a 32bit
environment is impossible on Linux. Due to the inability to map a memory
range in 16bit range.
