Spir-V frontend

[natgavrilenko]

No description provided.

[hernanponcedeleon]

Overall comment, whenever you get assumptions (e.g., coming from the specification), document these things because they are no trivial for someone that needs to read the code and might not be an expert on spirv

[ThomasHaas]

I thought of an alternative idea. Usually if we do not terminate, we still jump to the end of the thread.
The new ControlBarriers changes this fact which requires some updates here and there.
However, we could generate usual branching code like this:

E1: ControlBarrier(<id>)
E2: bool barrierNotExecuted = ExecutionStatus(E1) // Notice this returns TRUE if not executed
E3: if (barrierNotExecuted) goto END_OF_THREAD; ### EARLYTERMINATION

I.e., rather than giving control barriers special branching semantics, we just give them special execution semantics and then use standard branching on the execution semantics via a ExecutionStatus event.

This code could get fully generated at parsing time with the difference that the if-condition becomes an AbortIf(barrierNotExecuted) with Tag.EARLYTERMINATION.
As a consequence no code needs to get modified except the execution encoding of CBs and the stuckness encoding.

EDIT: I believe Tag.EARLYTERMINATION is misleading: we use it to mean both "nontermination" (spinloops, bound events, and soon control barriers(?)) and "irregular/exceptional termination" (assertion failure in C code).
We should probably split the tag into Tag.NONTERMINATION and Tag.IRREGULAR_TERMINATION.

EDIT 2: @hernanponcedeleon FYI, I implemented the above split in the executionModel branch.