[PATCH] D69281: [FPEnv] Constrained FCmp intrinsics

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

I would prefer to model the complete set of operations both in a signaling and quiet form.  It is true that IEEE does not define a named operation for each of these combinations, but it would still be useful:

- so we can model the capabilities of the hardware ISA (e.g. SystemZ and Power do have an instruction for any of these)
- and the compiler could in fact make use of them via optimization (e.g. an "isSignalingEqual" could be result of an optimization of "x <= y && x >= y").

Note that even today, not all of the predicate codes match an IEEE named operation, e.g. there is none corresponding to "one".

Now, assuming we want to model the complete set of operations, there would still be different ways to do so:

- use distinct intrinsics / opcodes to distinguish signaling vs. quiet operations, each carrying a predicate operand (like this patch currently does)
- use a single intrinsic / opcode with two operands (the predicate / condition code, and a boolean to indicate signaling vs. quiet)
- encode signaling vs. quiet status into the condition code, and use a single intrinsic / opcode with just one operand, the extended condition code

These ways would be generally equivalent, so it is a question of what seems easiest to implement.   I had initially experimented with using a single intrinsic / opcode with two operands, but in the end found the current solution with two opcodes simpler overall (in particular because of the setOperationAction issue discussed above).   I have not tried extended condition codes -- I'm not sure if this would run into issues elsewhere if those "leak" into other code currently handling condition code that is not aware of the new ones ...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69281/new/

https://reviews.llvm.org/D69281