On 11/13/22 13:48, Philipp Tomsich wrote:
For a straightforward application of bext for the following function
long bext64(long a, char bitno)
{
return (a & (1UL << bitno)) ? 0 : -1;
}
we generate
srl a0,a0,a1 # 7 [c=4 l=4] lshrdi3
andi a0,a0,1 # 8 [c=4 l=4] anddi3/1
addi a0,a0,-1 # 14 [c=4 l=4] adddi3/1
due to the following failed match at combine time:
(set (reg:DI 82)
(zero_extract:DI (reg:DI 83)
(const_int 1 [0x1])
(reg:DI 84)))
The existing pattern for bext requires the 3rd argument to
zero_extract to be a QImode register wrapped in a zero_extension.
This adds an additional pattern that allows an Xmode argument.
With this change, the testcase compiles to
bext a0,a0,a1 # 8 [c=4 l=4] *bextdi
addi a0,a0,-1 # 14 [c=4 l=4] adddi3/1
gcc/ChangeLog:
* config/riscv/bitmanip.md (*bext<mode>): Add an additional
pattern that allows the 3rd argument to zero_extract to be
an Xmode register operand.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbs-bext.c: Add testcases.
* gcc.target/riscv/zbs-bexti.c: Add testcases.
It's fairly common to want variants with extraction as well as a simple
register operand. The biggest concern is typically around
SHIFT_COUNT_TRUNCATED, but given we already have an extract variant
y'all should have already addressed concerns around SHIFT_COUNT_TRUNCATED.
OK.
jeff
