On Thu, Mar 07, 2024 at 10:55:12AM +0100, Richard Biener wrote:
> On Thu, 7 Mar 2024, Uros Bizjak wrote:
> > This is
> >
> > 3236 /* Just replace the CC reg with a new mode. */
> > 3237 SUBST (XEXP (*cc_use_loc, 0), newpat_dest);
> > 3238 undobuf.other_insn = cc_use_insn;
> >
> > in combine.cc, where *cc_use_loc is
> >
> > (unspec:DI [
> > (reg:CC 17 flags)
> > ] UNSPEC_PUSHFL)
> >
> > combine assumes CC must be used inside of a comparison and uses XEXP (...,
> > 0)
No. It has established *this is the case* some time earlier. Lines\
3155 and on, what begins with
/* Many machines have insns that can both perform an
arithmetic operation and set the condition code.
> > OK for trunk?
>
> Since you CCed me - looking at the code I wonder why we fatally fail.
I did not get this email btw. Some blip in email (on the sender's side)
I guess?
> The following might also fix the issue and preserve more of the
> rest of the flow of the function.
> --- a/gcc/combine.cc
> +++ b/gcc/combine.cc
> @@ -3182,7 +3182,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn
> *i1, rtx_insn *i0,
>
> if (undobuf.other_insn == 0
> && (cc_use_loc = find_single_use (SET_DEST (newpat), i3,
> - &cc_use_insn)))
> + &cc_use_insn))
> + && COMPARISON_P (*cc_use_loc))
Line 3167 already is
&& GET_CODE (SET_SRC (PATTERN (i3))) == COMPARE
so what in your backend is unusual?
Segher
