On Tue, 20 Sep 2016, Michael Meissner wrote: > It would be better to have a fpclassify<mode>2 pattern, and if it isn't > defined, then do the machine independent processing. That is the way it is > done elsewhere.
But note: * The __builtin_fpclassify function takes arguments for all the possible FP_* results, so the insn pattern would need to map the results to the arguments passed to __builtin_fpclassify. (They are documented as needing to be constants, of type int.) * Then you want that mapping step to get optimized away in the case of a comparison fpclassify (...) == FP_SUBNORMAL (for example), or a switch over possible results. Will the RTL optimizers do that given the insns structured appropriately? (For that matter, I don't know if the GIMPLE optimizers will optimize away such a mapping either, but they clearly should. I've wondered what the right approach would be for making FLT_ROUNDS properly depend on the rounding mode - bug 30569, <https://gcc.gnu.org/ml/gcc/2013-11/msg00317.html> - where the same issues apply. For boolean operations such as isnan you don't have such complications.) * If flag_signaling_nans, then any pattern should work for signaling NaNs. -- Joseph S. Myers jos...@codesourcery.com
