Hi!
First, you need to adjust after Robin's patch, and retest.
On Thu, Feb 17, 2022 at 01:56:04PM -0500, Michael Meissner wrote:
> Don't do int cmoves for IEEE comparisons, PR target/104256.
> Unfortunately there are some conditions like UNLE that can't easily be
> reversed
> due to NaNs.
What do you mean? The reverse of UNLE is GT. You don't even need to
check if fast-math is active, or whether this is FP at all -- that is a
*given* if you see UNLE!
You need more context to reverse GT. For fast-math and integer that
gives LE, for fp it is UNLE.
> The patch changes the code so that it does the reversal before generating the
> comparison. If the comparison cannot be reversed, it just returns false,
> which indicates that we can't do an int conditional move in this case.
> + /* Swap the comparison if isel can't handle it directly. Don't generate
> int
> + cmoves if we can't swap the condition code due to NaNs. */
"swap" has a specific meaning for comparisons, and this isn't it (it
refers to swapping the arguments).
You can do the reverse condition for all codes that include UN just
fine. reversed_comparison knows how to do this.
> + enum rtx_code op_code = GET_CODE (op);
> + if (op_code != LT && op_code != GT && op_code != LTU && op_code != GTU
> + && op_code != EQ)
There are functions to test this. Perhaps scc_comparison_operator
and exclude unordered? But, this seems wrong, as said.
> - switch (cond_code)
> - {
> - case LT: case GT: case LTU: case GTU: case EQ:
> - /* isel handles these directly. */
> - break;
Ah, you got that from existing code. Well, a good chance to improve
things, isn't it :-)
> new file mode 100644
> index 00000000000..d1bfab23482
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/ppc-fortran/pr104254.f90
> @@ -0,0 +1,25 @@
> +! { dg-do compile }
> +! { dg-require-effective-target powerpc_p9vector_ok }
> +! { dg-options "-mdejagnu-cpu=power9 -O1 -fnon-call-exceptions" }
> +
> +! PR target/104254. GCC would raise an assertion error if this program was
PR104256.
Segher
