This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible
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.