diff mbox series

[33/44] RISC-V: Also allow FP conditions in `riscv_expand_conditional_move'

Message ID alpine.DEB.2.20.2311182143010.5892@tpp.orcam.me.uk
State New
Headers show
Series RISC-V: Various if-conversion fixes and improvements | expand

Commit Message

Maciej W. Rozycki Nov. 19, 2023, 5:42 a.m. UTC 
In `riscv_expand_conditional_move' we only let integer conditions 
through at the moment, even though code has already been prepared to 
handle floating-point conditions as well.

Lift this restriction and only bail out if a non-word-mode integer 
condition has been requested, as we cannot handle this specific case 
owing to machine instruction set restriction.  We already take care of 
the non-integer, non-floating-point case later on.

	gcc/
	* config/riscv/riscv.cc (riscv_expand_conditional_move): Don't 
	bail out in floating-point conditions.
---
 gcc/config/riscv/riscv.cc |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

gcc-riscv-expand-conditional-move-fp.diff

Comments

Jeff Law Nov. 19, 2023, 6:30 p.m. UTC | #1 
On 11/18/23 22:42, Maciej W. Rozycki wrote:
> In `riscv_expand_conditional_move' we only let integer conditions
> through at the moment, even though code has already been prepared to
> handle floating-point conditions as well.
> 
> Lift this restriction and only bail out if a non-word-mode integer
> condition has been requested, as we cannot handle this specific case
> owing to machine instruction set restriction.  We already take care of
> the non-integer, non-floating-point case later on.
> 
> 	gcc/
> 	* config/riscv/riscv.cc (riscv_expand_conditional_move): Don't
> 	bail out in floating-point conditions.
I probably goof'd something when merging up the eswin, vrull and ventana 
changes in this space.  I recall fixing multiple bugs in handling FP 
conditional moves when building/testing spec2017 internally -- so this 
was supposed to be working.


OK for the trunk.

Jeff
Maciej W. Rozycki Nov. 23, 2023, 10:55 p.m. UTC | #2 
On Sun, 19 Nov 2023, Jeff Law wrote:

> > Lift this restriction and only bail out if a non-word-mode integer
> > condition has been requested, as we cannot handle this specific case
> > owing to machine instruction set restriction.  We already take care of
> > the non-integer, non-floating-point case later on.
> > 
> > 	gcc/
> > 	* config/riscv/riscv.cc (riscv_expand_conditional_move): Don't
> > 	bail out in floating-point conditions.
> I probably goof'd something when merging up the eswin, vrull and ventana
> changes in this space.  I recall fixing multiple bugs in handling FP
> conditional moves when building/testing spec2017 internally -- so this was
> supposed to be working.

 This didn't matter though, because before 34/44 FP conditions could never 
make it here, not at least with pristine upstream code.

  Maciej
diff mbox series

Patch

Index: gcc/gcc/config/riscv/riscv.cc
===================================================================
--- gcc.orig/gcc/config/riscv/riscv.cc
+++ gcc/gcc/config/riscv/riscv.cc
@@ -4109,12 +4109,12 @@  riscv_expand_conditional_move (rtx dest,
       machine_mode mode0 = GET_MODE (op0);
       machine_mode mode1 = GET_MODE (op1);
 
-      /* The comparison must be comparing WORD_MODE objects.   We must
-	 enforce that so that we don't strip away a sign_extension
+      /* An integer comparison must be comparing WORD_MODE objects.  We
+	 must enforce that so that we don't strip away a sign_extension
 	 thinking it is unnecessary.  We might consider using
 	 riscv_extend_operands if they are not already properly extended.  */
-      if ((mode0 != word_mode && mode0 != VOIDmode)
-	  || (mode1 != word_mode && mode1 != VOIDmode))
+      if ((INTEGRAL_MODE_P (mode0) && mode0 != word_mode)
+	  || (INTEGRAL_MODE_P (mode1) && mode1 != word_mode))
 	return false;
 
       /* In the fallback generic case use MODE rather than WORD_MODE for