[26/44] RISC-V: Add `movMODEcc' implementation for generic targets

Provide RTL expansion of conditional-move operations for generic targets 
using a suitable sequence of base integer machine instructions according 
to cost evaluation by if-conversion.  Add `-mmovcc' command line option 
to enable this transformation, off by default.

For the generic sequences small immediates as per the `arith_operand' 
predicate are cost-equivalent to registers as we can use them as input, 
alternative to a register, to the respective AND[I] machine operations, 
however we need to reject immediates fulfilling `lui_operand', because 
they would require reloading into a register, making the operation more 
costly.  Therefore add `movcc_operand' predicate and use it accordingly.

There is a need to adjust zbs-bext-02.c, which can also serve as emitted 
code example, because with certain compilation options an AND operation 
can now legitimately appear in output despite BEXT having been produced 
as expected, such as with `-march=rv64gc -O2':

foo:
	mv	a3,a0
	li	a5,0
	mv	a0,a1
	li	a2,64
	li	a1,1
.L3:
	sll	a4,a1,a5
	and	a4,a4,a3
	addiw	a5,a5,1
	beq	a4,zero,.L2
	addiw	a0,a0,1
.L2:
	bne	a5,a2,.L3
	ret

vs `-march=rv64gc_zbs -O2':

foo:
	mv	a4,a0
	li	a5,0
	mv	a0,a1
	li	a3,64
.L3:
	bext	a2,a4,a5
	beq	a2,zero,.L2
	addiw	a0,a0,1
.L2:
	addiw	a5,a5,1
	bne	a5,a3,.L3
	ret

and then with `-march=rv64gc -mmovcc -mbranch-cost=7':

foo:
	mv	a6,a0
	li	a4,0
	mv	a0,a1
	li	a7,1
	li	a1,64
.L3:
	sll	a5,a7,a4
	and	a5,a5,a6
	snez	a5,a5
	neg	a5,a5
	not	a2,a5
	addiw	a3,a0,1
	and	a5,a5,a3
	and	a0,a2,a0
	addiw	a4,a4,1
	or	a0,a5,a0
	bne	a4,a1,.L3
	ret

vs `-march=rv64gc_zbs -mmovcc -mbranch-cost=7':

foo:
	mv	a6,a0
	li	a4,0
	mv	a0,a1
	li	a1,64
.L3:
	bext	a5,a6,a4
	neg	a5,a5
	not	a2,a5
	addiw	a3,a0,1
	and	a5,a5,a3
	and	a0,a2,a0
	addiw	a4,a4,1
	or	a0,a5,a0
	bne	a4,a1,.L3
	ret

However BEXT is supposed to replace an SLL operation so adjust the test 
case to reject SLL rather than AND, letting the test case pass even with 
`/-mmovcc/-mbranch-cost=7' specified as DejaGNU test flags (and in the 
absence of target-specific conditional-move operations enabled either by 
default or with other test flags).

	gcc/
	* config/riscv/predicates.md (movcc_operand): New predicate.
	* config/riscv/riscv.cc (riscv_expand_conditional_move): Handle
	generic targets.
	* config/riscv/riscv.md (mov<mode>cc): Likewise.
	* config/riscv/riscv.opt (mmovcc): New option.
	* doc/invoke.texi (Option Summary): Document it.

	gcc/testsuite/
	* gcc.target/riscv/zbs-bext-02.c: Adjust to reject SLL rather 
	than AND.
---
 gcc/config/riscv/predicates.md               |    6 +++
 gcc/config/riscv/riscv.cc                    |   41 ++++++++++++++++++++++-----
 gcc/config/riscv/riscv.md                    |    7 ++--
 gcc/config/riscv/riscv.opt                   |    4 ++
 gcc/doc/invoke.texi                          |    9 +++++
 gcc/testsuite/gcc.target/riscv/zbs-bext-02.c |    2 -
 6 files changed, 58 insertions(+), 11 deletions(-)

gcc-riscv-movcc.diff

On 11/18/23 22:40, Maciej W. Rozycki wrote:
> Provide RTL expansion of conditional-move operations for generic targets
> using a suitable sequence of base integer machine instructions according
> to cost evaluation by if-conversion.  Add `-mmovcc' command line option
> to enable this transformation, off by default.
> 
> For the generic sequences small immediates as per the `arith_operand'
> predicate are cost-equivalent to registers as we can use them as input,
> alternative to a register, to the respective AND[I] machine operations,
> however we need to reject immediates fulfilling `lui_operand', because
> they would require reloading into a register, making the operation more
> costly.  Therefore add `movcc_operand' predicate and use it accordingly.
> 
> There is a need to adjust zbs-bext-02.c, which can also serve as emitted
> code example, because with certain compilation options an AND operation
> can now legitimately appear in output despite BEXT having been produced
> as expected, such as with `-march=rv64gc -O2':
> 
> foo:
> 	mv	a3,a0
> 	li	a5,0
> 	mv	a0,a1
> 	li	a2,64
> 	li	a1,1
> .L3:
> 	sll	a4,a1,a5
> 	and	a4,a4,a3
> 	addiw	a5,a5,1
> 	beq	a4,zero,.L2
> 	addiw	a0,a0,1
> .L2:
> 	bne	a5,a2,.L3
> 	ret
> 
> vs `-march=rv64gc_zbs -O2':
> 
> foo:
> 	mv	a4,a0
> 	li	a5,0
> 	mv	a0,a1
> 	li	a3,64
> .L3:
> 	bext	a2,a4,a5
> 	beq	a2,zero,.L2
> 	addiw	a0,a0,1
> .L2:
> 	addiw	a5,a5,1
> 	bne	a5,a3,.L3
> 	ret
> 
> and then with `-march=rv64gc -mmovcc -mbranch-cost=7':
> 
> foo:
> 	mv	a6,a0
> 	li	a4,0
> 	mv	a0,a1
> 	li	a7,1
> 	li	a1,64
> .L3:
> 	sll	a5,a7,a4
> 	and	a5,a5,a6
> 	snez	a5,a5
> 	neg	a5,a5
> 	not	a2,a5
> 	addiw	a3,a0,1
> 	and	a5,a5,a3
> 	and	a0,a2,a0
> 	addiw	a4,a4,1
> 	or	a0,a5,a0
> 	bne	a4,a1,.L3
> 	ret
> 
> vs `-march=rv64gc_zbs -mmovcc -mbranch-cost=7':
> 
> foo:
> 	mv	a6,a0
> 	li	a4,0
> 	mv	a0,a1
> 	li	a1,64
> .L3:
> 	bext	a5,a6,a4
> 	neg	a5,a5
> 	not	a2,a5
> 	addiw	a3,a0,1
> 	and	a5,a5,a3
> 	and	a0,a2,a0
> 	addiw	a4,a4,1
> 	or	a0,a5,a0
> 	bne	a4,a1,.L3
> 	ret
> 
> However BEXT is supposed to replace an SLL operation so adjust the test
> case to reject SLL rather than AND, letting the test case pass even with
> `/-mmovcc/-mbranch-cost=7' specified as DejaGNU test flags (and in the
> absence of target-specific conditional-move operations enabled either by
> default or with other test flags).
> 
> 	gcc/
> 	* config/riscv/predicates.md (movcc_operand): New predicate.
> 	* config/riscv/riscv.cc (riscv_expand_conditional_move): Handle
> 	generic targets.
> 	* config/riscv/riscv.md (mov<mode>cc): Likewise.
> 	* config/riscv/riscv.opt (mmovcc): New option.
> 	* doc/invoke.texi (Option Summary): Document it.
> 
> 	gcc/testsuite/
> 	* gcc.target/riscv/zbs-bext-02.c: Adjust to reject SLL rather
> 	than AND.
OK.  Just curious are y'all seeing significant interest in this case 
from customers or is this more a case of rounding out the implementation 
to cover all potential possibilities?



Jeff

On Sun, 19 Nov 2023, Jeff Law wrote:

> OK.  Just curious are y'all seeing significant interest in this case from
> customers or is this more a case of rounding out the implementation to cover
> all potential possibilities?

 As in the cover letter: we have a case where the pipeline seems to imply 
high enough a branch penalty for branchless alternatives to be worth 
considering even where built from more than just a couple instructions.  
We yet have to fully evaluate it for our case and it may be that these 
sequences are costlier than branches after all or that the boundary lies 
somewhere in between (or that we end up with Zicond also available in the 
CPU RTL).  However we realised that combined with `-mbranch-cost=' it 
might be a useful tool for performance evaluation for other people as 
well.

 This, combined with the branch costing issues observed earlier and 
attempted to address with 09/44, is also why I chose, conservatively, to 
add the `-mmovcc' option to control this feature: we may choose to flip it 
on by default for some tuning architectures or even globally at one point.  
Especially as it seems like the `addMODEcc' part could be profitable for 
some architectures already.

  Maciej