This is something that TSAN caught was happening.
Grabs the thread creation mutex when checking for idle and extends the
sleep time for WaitForIdle to something that is still below unit test
run time
The VFORK flag lets clone behaviour similarly to a fork.
The parent will be suspended until the resulting thread is exited
The mutex is removed because everything that touches state is already
wrapped by mutexes. So we don't need this one
This was implemented with the glibc API originally which was incorrect.
The syscall API is just a simple bitmask of for the affinity of the
number of CPU cores and a size check that the resulting structure is
large enough to store the number of bits.
Sadly this is a fairly substantial change that can't be broken in to
something smaller.
The gist of the problem is that most of the vector ops declared their
own uint8_t RegisterSize and ElementSize variables in their structs.
This was initially done because there were assumptions elsewhere in the
source that sometimes mixed up the IROp member `Size` and `Elements` as
sometimes meaning `Size` elements and `Elements` number of elements.
Other times there was an assumption that `Size` was the full register
size and `Elements` was the number of elements inside that size.
ex: `Size`: 16, `Elements` 8 would sometimes be interpreted as i8v16 OR i128v8
These assumptions are now removed and we also save on average 16bits per
vector operation. This is a necessary evil first step for upcoming IR
considerations.
This should have zero change on runtime behaviour and unit tests confirm
that.
Changes the IR register class definition to exist in the JSON file.
Removes a couple of IR ops that were unused and weren't necessary.
Changes the CPUID IR op to the new paired op which improves perf ever so
slightly.
Changes RA class handling in the RA pass to pull directly from the new
generated helper routine until it hits a complex op
Still need RA constraints to remove extraneous moves that would crop up
Consolidates usage of register class to the one that is defined in the
IR Json file.
Every magic number is replaced with InvalidClass and instead uses the
enums directly
Another bug fix is that the GetHostFlags IR ops was being declared as
using the flags register class, which isn't a real thing yet.
This would most likely have ended up with host flag usage being
scheduled to a GPR that was already scheduled and overwrite it.
Once this IR op ends up in host flags this will be changed as well
There are still some extraneous moves generated around the instruction,
but we need RA instruction constraints in order to safely (and cleanly)
remove them
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.
behaviour around enabling PIC it was only working on one platform.
This follows through with the NEW cmake behaviour required to enable
PIE.
Very specifically you have to set the cmake variable, you have to set
the new policy, AND you have to have an explicit check for pie support.
With any of those three things missing then PIE won't be enabled
When a Zext is going 64bit->128bit this involves a register class change.
This is special cased in the CPU cores and the const prop class doesn't
really have a way to handle this case in the IR level
Ryan Houdek