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
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.
We need to reserve that space for EXEC apps and 32bit apps. Hard throw a
warning if any of our mapping space ends up in the lower 32bits.
PIE and potentially a custom dynamic linker can enforce this.
Fixes#49
Makes it so we no longer have to pass in the ld location to the
ELFLoader application.
Once we switch over to the dynamic linker, the program being executed to
us is no longer a dynamic program.
But the frontend ELF loader also still needs to know that we are
executing the dynamic linker so it can append the linker to the
arguments.
These were messy and we were previously losing a page for random
"redzone" which doesn't matter.
We only needed 16bytes more for some additional padding that was needed
for something
Ryan Houdek