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.) Segher
