https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123092
Peter Bergner <bergner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bergner at gcc dot gnu.org
--- Comment #8 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Vineet Gupta from comment #7)
> The preetch pattern as defined allows PLUS but then requires operand0 to be
> a register, but it seems LRA is not honoring that for some reason.
>
> Haven't looked into why LRA is doing this.
The prefetch pattern looks like:
(define_insn "prefetch"
[(prefetch (match_operand 0 "prefetch_operand" "Qr,ZD")
(match_operand 1 "imm5_operand" "i,i")
(match_operand 2 "const_int_operand" "n,n"))]
"TARGET_ZICBOP || TARGET_XMIPSCBOP"
...
The Qr constraint correctly rejects the (plus:DI (mem...)) operand. LRA then
checks if there is another alternative that works, so it tries the ZD
constraint. I would have assumed that MIPS specific constraint would reject
everything when we're not compiling for MIPS CBOP, but it doesn't and actually
accepts this address.
I assume we'd want to change the ZD constraint to be defined like so?
(define_address_constraint "ZD"
"An address operand that is valid for a mips prefetch instruction"
- (match_test "riscv_prefetch_offset_address_p (op, mode)"))
+ (match_test "TARGET_XMIPSCBOP && riscv_prefetch_offset_address_p (op,
mode)"))
However, even doing that, we still ICE, but with a slightly better error
message:
pr123092.i:10:1: error: insn does not satisfy its constraints:
10 | }
| ^
(insn 8 12 13 2 (prefetch (plus:DI (mem/f/c:DI (lo_sum:DI (reg/f:DI 10 a0
[137])
(symbol_ref:DI ("d") [flags 0x86] <var_decl 0x7f68cc52e000
d>)) [1 d.b+0 S8 A64])
(const_int 64 [0x40]))
(const_int 0 [0])
(const_int 3 [0x3])) "pr123092.i":7:3 500 {prefetch}
(nil))
during RTL pass: reload
...so the same bad insn, we just end up catching it earlier than without the
change to the ZD constraint.
