https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117699
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> Hmm, reading
> https://gcc.gnu.org/onlinedocs/gccint/define_005fpeephole2.html#index-
> define_005fpeephole2 gives an impression if the scratch register is needed
> not to conflicting with the output then a match_dup is needed too.
>
>
> ```
> Scratch registers are requested with a match_scratch pattern at the top
> level of the input pattern. The allocated register (initially) will be dead
> at the point requested within the original sequence. If the scratch is used
> at more than a single point, a match_dup pattern at the top level of the
> input pattern marks the last position in the input sequence at which the
> register must be available.
> ```
>
> Ths is this would correct:
> ```
> (define_peephole2
> [(match_scratch:QI 3 "d")
> (parallel [(set (match_operand:ALL4 0 "register_operand" "")
> (ashift:ALL4 (match_operand:ALL4 1 "register_operand" "")
> (match_operand:QI 2 "const_int_operand" "")))
> (clobber (reg:CC REG_CC))])
> (match_dup 3)]
> ```
Thanks. You are the greatest!
That fixes the problem, even without any changes to recog.cc (at least for the
test case).
Plus, without my WIP patch to the avr BE, there's no problem beacause the insn
in the peephole are only 2-operand insns with $0 = $1; so no problem because $3
won't overlap with the input $1.
