On Fri, Dec 18, 2020 at 06:13:22PM +0100, Georg-Johann Lay wrote: > Segher Boessenkool schrieb: > >On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote: > >>>On Dec 17, 2020, at 6:21 AM, Segher Boessenkool > >>><seg...@kernel.crashing.org> wrote: > >>>On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via > >>>Gcc-patches wrote: > >>>>The work on my github branch was not complete - I'd blindly followed > >>>>whatever the CC0 Transition wiki mentioned (the first three steps of > >>>>case #2), and fixed any regression fallout (for ATmega128). > >>>> > >>>>I intend to try out a define_subst/early clobber of reg_cc based > >>>>approach (inspired by the cris port) and see if that can help avoid the > >>>>proliferation of define_insn_and_splits. Will update how that works out. > >>>Yeah, case #2 does not necessarily give the best result, but it usually > >>>is the least work to do, so certainly a good choice under time pressure. > >>I was under the impression from what I read in the blog a year or two ago > >>(when I did the pdp11 ccmode work) that "case 2" is the better answer for > >>machines in which pretty much every operation touches the condition > >>codes. In other words, I understood that case 1 would for such machines > >>not be the right answer -- it wasn't just that "case 2 is easier". > >> > >>Did I misunderstand? Is there a reason for machines such as pdp11, in > >>which basically every operation that handles data, even a move > >>instruction, touches CC, to use approach 1? > > > >No, you didn't misunderstand. I said "not necessarily" for a reason :-) > > > >If there are move insns that do *not* clobber CC, it can be different, > >but if even move instructions do, a case #2 conversion is a good choice. > > > >(This is all my opinion, but I think it is not controversial.) > > As far as I understand, targets that clobber condition code in mov<mode> > or add<pmode>3 must use approach #2.
If there is no way to reload without clobbering CC, yeah. Often you *can* reload that way, at big cost (push the flags to the stack around the move, for example), but if you need that for common insns, this is no good. > #1 is not a problem if the target > still uses IRA (like avr does), but LRA cannot handle clobbers of the > condition code (in terms or explicit clobbers). (still uses reload) I'm not sure what the LRA thing means? The rs6000 port has many patterns that clobber some specific CR reg. If it is important here that there is only one such reg, thyen we also clobber the CA reg in many patterns (the carry bit, there is only one of those). Or is this only wrt mov and add as well? > Hence, targets that clobber cc in mov<mode> or add<pmode>3 must > use #2 because IRA/reload will also be kicked out before very soon. > > Or am I missing something? compare-elim.c claims this same thing: There is a set of targets whose general-purpose move or addition instructions clobber the flags. These targets cannot split their CBRANCH/CSTORE etc patterns before reload is complete, lest reload itself insert these instructions in between the flags setter and user. so you might well be right :-) Thanks, Segher
