On Wed, 21 Sep 2016, Joseph Myers wrote: > 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.)
Yeah, that's the reason we "lower" this early. > * 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? I think it makes sense to fold fpclassify (...) == N to more specific classification builtins that do not have this issue if possible. OTOH RTL expansion could detect some of the non-builtin ways to do such checks and see if an optab exists as well. > (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.) I think they do via jump-threading. Richard.