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