This will become important in the future when we are actually executing
this code directly on host.
FEX itself doesn't yet care about memory permissions
This allows us to only check for the lower 64bits of the MM registers
when doing MMX ops for example.
Top 16bits in that case is undefined and needs to be ignored
All the previous fixed offset problems are now fixed so we can flick
this on.
We still allocate memory regions at fixed addresses, but due to
enforcing pie this is fine.
This will install a binfmt_misc target for x86_64 targets that allows
FEXLoader to be the interpreter.
Everything else is already set up to allow this to work, just time to
hook it up.
This requires implementing custom ASM dispatchers for the interpreter
side of things so it works correctly.
Allows all of our CPU backends to safely support signaling.
This is a bit of a nightmare change and requires rethinking logic about
debugging in some instances.
This is just a virtual number that the guest can query through the
various means. Will affect mesa with how many helper threads it
generates at the very least
The IRHeader itself contains a flag for if a block should fallback to
the interpreter.
This is necessary for the case that an IR is loaded and the Frontend
object no longer has the data necessary to know if it should do an
interpreter fallback.
This is super useful for bisecting JIT versus Intepreter failures, and
also cases where falling back to intepreter for compatibility is a lot
more simple than wiring things through the JIT (ala x87)
This isn't currently utilized, but will be once x87 work lands
Elements of 0 isn't a real thing. Would cause problems in the CPU
backends.
Ensure we have at least 1 element (Which technically means a vector 1
element wide, but that just defines as a scalar)
Comments start with ';' on the line.
You can also technically have comments after IR ops but that isn't
explicitly supported, just an artifact of how things are parsed.
The Passmanager passes need very little or zero x86 knowledge to do
their work. They don't need the x86 OpDispatcher handling code at all.
Convert this entirely over to using the IREmitter class so it can
actually optimize IR code from the IRLoader frontend
This application loads an IR from an IR file.
It then proceeds to lex the file and translate it to binary IR.
Once the file is loaded it then the IR is passed off to the backend and
it attempts to run the IR.
This will be used when debugging RA and writing unit tests directly in
IR.
This is a necessary evil for ensuring correctness
If we are loading EXEC then we actually need to start loading in to the
lower 32bits of memory.
This lets the frontend code loader handle the memory base instead of
hiding it behind some core magic instead.
This lets us get EXEC programs working.
So now we support EXEC, DYN, and static applications
4GB virtual memory is too small and causes things to fault.
Previously we were at `1 << 36` but it caused oom issues on devices with
smaller amounts of memory.
This time ensure the the SHM memory is allocated with MEM_NORESERVE so
devices can actually allocate the virtual memory region.
Ryan Houdek