Phase 3 presentation feedback

[ngzhian]

I presented about our progress at the 2022-04-12 CG meeting, and successfully polled to advance to phase 3. This issue tracks feedback from the CG. The key feedback is about the correlation between the cases of an instruction.

CG suggested loosening the correlation between cases, e.g.

Currently, an implementation will have to pick one column for all the cases, and the column must be the same for all cases. This might be too strict, and may be difficult to maintain this correlation when performing optimizations in the toolchain.

Besides, the behavior of such "corner cases" shouldn't be relied on by users, by requiring such correlation, there is a higher risk of people relying on such detection patterns (which already exists).

The suggestion is that for each of the cases (i.e. each row in the relaxed_min above), it is not specified that you always get the same column. Treat the results as sets return of the elements in the set. Essentially, the result is now non-deterministic, rather than implementation-defined.

I noted that we originally specified such a fixed projection to ensure that 2 consecutive instructions with the same input should return the same result. This is important for instructions like Relaxed FMA. E.g. an algorithm would use Relaxed FMA with special inputs to determine if is fused or not. At the time of presentation, I had no concrete example, but Marat has one (https://hal.inria.fr/inria-00000895/document look for Fast2Mult).

I suggest that we word it such that implementations have to pick one column for each of the listed cases, but it not be the same column for each case. This removes the correlation between cases (like in min/max), but preserves the property that a FMA is always fused or always not fused.