On 5/23/23 06:27, Richard Sandiford wrote:
Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
On 5/17/23 03:03, Jin Ma wrote:
For example:
(define_insn "mov_lowpart_sidi2"
[(set (match_operand:SI 0 "register_operand" "=r")
(subreg:SI (match_operand:DI 1 "register_operand" " r") 0))]
"TARGET_64BIT"
"mov\t%0,%1")
(define_insn "mov_highpart_sidi2"
[(set (match_operand:SI 0 "register_operand" "=r")
(subreg:SI (match_operand:DI 1 "register_operand" " r") 1))]
"TARGET_64BIT"
"movh\t%0,%1")
When defining the above patterns, the generated file insn-recog.cc will
appear 'switch (SUBREG_BYTE (op))', but since the return value of
SUBREG_BYTE is poly_uint16_pod, the following error will occur:
"error: switch quantity not an integer".
gcc/ChangeLog:
* genrecog.cc (print_nonbool_test): Fix type error of
'switch (SUBREG_BYTE (op))'.
Thanks. Installed.
We shouldn't add to_constant just because it's a convenient
way of getting rid of errors :) There has to be a good reason
in principle why the value is known at compile time.
Agreed. I fully expected the constant to be known at compile time. I
wasn't aware we had real uses of polys in the SUBREG_BYTE field.
So I think this should be reverted. Nothing guarantees that
SUBREG_BYTEs are constant on AArch64 and RISC-V. And for SVE
it's common for them not to be.
That's fine with me.
Jeff
