Question about insn predicates and constraints
Richard Sandiford
rdsandiford@googlemail.com
Sun Sep 30 09:21:00 GMT 2012
Andreas Schwab <schwab@linux-m68k.org> writes:
> m68k.md contains the following insn:
>
> (define_insn ""
> [(set (match_operand:SI 0 "nonimmediate_operand" "=&d")
> (zero_extract:SI (match_operand:SI 1 "register_operand" "do")
> (match_operand:SI 2 "const_int_operand" "n")
> (match_operand:SI 3 "const_int_operand" "n")))]
> "TARGET_68020 && TARGET_BITFIELD
> && (INTVAL (operands[2]) == 8 || INTVAL (operands[2]) == 16)
> && INTVAL (operands[3]) % INTVAL (operands[2]) == 0
> && (GET_CODE (operands[1]) == REG
> || ! mode_dependent_address_p (XEXP (operands[1], 0),
> MEM_ADDR_SPACE (operands[1])))"
> {
> cc_status.flags |= CC_NOT_NEGATIVE;
> if (REG_P (operands[1]))
> {
> if (INTVAL (operands[2]) + INTVAL (operands[3]) != 32)
> return "bfextu %1{%b3:%b2},%0";
> }
> else
> operands[1]
> = adjust_address (operands[1], SImode, INTVAL (operands[3]) / 8);
>
> output_asm_insn ("clr%.l %0", operands);
> if (GET_CODE (operands[0]) == MEM)
> operands[0] = adjust_address (operands[0],
> INTVAL (operands[2]) == 8 ? QImode : HImode,
> (32 - INTVAL (operands[1])) / 8);
>
> if (INTVAL (operands[2]) == 8)
> return "move%.b %1,%0";
> return "move%.w %1,%0";
> })
>
> It is my understanding that given the register_operand predicate on op1
> it can never be a MEM expressions, thus the call to
> mode_dependent_address_p in the condition is useless, and the "o"
> constraint is redundant.
Worse than redundant really. If the register operand is a spilled pseudo,
"o" allows reload to replace the operand with a stack memory reference,
which would lead to an ICE after reload. (Reload only checks constraints
in that situation, not predicates.)
Which is just a way of saying that there were even more reasons for
making the change you wanted to make...
Richard
More information about the Gcc
mailing list