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.


Reply via email to