On Fri, Dec 13, 2019 at 08:55:15PM +0100, Stefan Franke wrote:
> Am 2019-12-13 18:58, schrieb Segher Boessenkool:
> >On Fri, Dec 13, 2019 at 05:25:41PM +0100, Stefan Franke wrote:
> >>Why? If you are using a cc register plus your architecture as many
> >>instructions which may clobber that cc register, some passes (e.g.
> >>gcse)
> >>will reorder the insns. This can lead to the situation that an insn is
> >>moved between a compare and it' consuming jump insn. Which yields
> >>invalid code. (Note that at these stages clobbers are not yet tracked
> >>as
> >>CLOBBER insns).
> >
> >Then that port has a bug. In the m68k port, there are no separate
> >compare
> >and jump insns ever, but for most ports those won't yet exist during
> >gcse.
>
> it looks like t2o insn for the m68k
>
> (insn 115 114 116 5 (set (cc0)
> (compare (subreg:HI (reg:SI 272) 2)
> (reg:HI 273)))
> /tmp/compiler-explorer-compiler1191113-13975-1allrsj.w8mc/example.c:216
> 17 {*m68k.md:559}
> (nil))
> (jump_insn 116 115 117 5 (set (pc)
> (if_then_else (ne (cc0)
> (const_int 0 [0]))
> (label_ref 99)
> (pc)))
> /tmp/compiler-explorer-compiler1191113-13975-1allrsj.w8mc/example.c:216
> 411 {bne}
> (int_list:REG_BR_PROB 4 (nil))
> -> 99)
This is an older compiler. m68k no longer uses cc0 (except it is still
mentioned in two comments (well, commented-out code)).
> >This is not unique to cc0 conversions: every port has a similar problem
> >with all FIXED_REGISTERS.
>
> It's not related to fixed registers.
No, it is exactly the same situation. You cannot introduce uses of such
a register if it might already exist in the insn stream somewhere, not
without checking first, and you better have a backup plan too.
> It's unique to CC registers since
> these are on some plattforms modified by side effects. So after split2
> it's modelled using CLOBBERs
There are no such implicit side effects if you have gotten rid of cc0.
That is the *point* of removing cc0.
> >@findex cc0_rtx
> >There is only one expression object of code @code{cc0}; it is the
> >value of the variable @code{cc0_rtx}. Any attempt to create an
> >expression of code @code{cc0} will return @code{cc0_rtx}.
> >
> >There is a lot of code that depends on this property, you cannot break
> >it without fixing everything.
>
> There is no need to change the definition or modify any piece elsewhere.
> And the modified comparison will still work for cc0.
Then you do not need your patch. You can compare cc0_rtx by identity.
Segher
