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.
Just ensures that it gets stored in the correct XDG or ~/ config
directories.
If these don't exist then it'll get dumped in to PWD or cwdir, whichever
is available as fallback
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
In the case of multiple dozens of tests running, they will end up
loading and saving the config files dozens of times.
This was causing the configuration system to load in half saved files
that were causing common crashes in the posix unit tests.
Theoretically this could have happened at any time but it looks like
with the posix unit tests added, it is just more likely to happen.
Makes it so loading the configuration file is much more robust and
verbose on failure.
Makes it so saving the config file first saves to a temporary and then
moves in to the correct location. This causes the config saving to be
atomic in a sense so the unit tests won't corrupt other processes of FEX
trying to load the config file.
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
Ryan Houdek