https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119587
--- Comment #1 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So I finally took a bit of time and dug into this.
My first inclination was that can_combine_p should have rejected this case, but
given insns A and B where we want to combine A into B. can_combine_p is
primarily concerned that A does not have an ASM_INPUT. B is allowed to have an
ASM_INPUT.
After combining A into B we eventually work our way into asm_operand_ok via
check_asm_operands via recog_for_combine.
asm_operand_ok succeeds because "A" is marked as a special memory operand in
the RISC-V backend.
(define_memory_constraint "A"
"An address that is held in a general-purpose register."
(and (match_code "mem")
(match_test "GET_CODE(XEXP(op,0)) == REG")))
And if we look at how special memory operands are handled:
case CT_SPECIAL_MEMORY:
/* Every memory operand can be reloaded to fit. */
if (!mem)
mem = extract_mem_from_operand (op);
result = result || memory_operand (mem, VOIDmode);
break;
So yes, it just extracts the address (reg+reg) and since thead considers
reg+reg valid memory_operand returns true.
So ultimately we have to provide a reload path. So that original proposed
patch, while unpleasant, is probably a reasonable path forward.
