Re: [PATCH] avr: cc0 to mode_cc conversion

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
> > On Dec 17, 2020, at 6:21 AM, Segher Boessenkool <segher@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