> On Dec 17, 2020, at 6:21 AM, Segher Boessenkool <seg...@kernel.crashing.org>
> wrote:
>
> Hi!
>
> 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?
paul
