Re: AVR: CC0 to CCmode conversion

[Paul Schlie <schlie at comcast dot net>]

> From: Denis Chertykov <denisc@overta.ru>
>> Paul Schlie <schlie@comcast.net> writes:
>>> Denis wrote:
>>> I have converted the AVR port from CC0 to CCmode.
>>> But may be I have converted the port in wrong way.
>>> (It's because I was interested in *this* way.)
>>> 
>>> I have used CCmode register and havn't added the
>>> '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the
>>> CC_REGNUM just because AVR is'n needed in scheduling.
>>> I think that sequence of compare + cond-jump will exists in any
>>> compiler pass.
>>> The port was successfully tested without new regressions.
>>> What do you (MAINTAINERS) think about this ?
>> 
>> Interesting:
>> 
>> - might you be able to post the resulting port files for review?
> 
> patch against cvs:
> http://home.overta.ru/users/denisc/cc0-ccmode/cc0-ccmode.patch.gz
> new port:
> http://home.overta.ru/users/denisc/cc0-ccmode/avr.tgz

- Thank you, I've had the chance to review it to better understand.

>> - are you proposing that all conditional branches then required to be
>>   explicitly paired with a corresponding immediately previous compare
>>   instruction?
> 
> I founded that GCC isn't break cmp+jump sequences.
> (My port havn't scheduling.)

- Maybe presently, but there's nothing in the machine description which
  would seem to prohibit it either. (continued in following section)

>>   (if so, how is this a good thing observing that it's fairly typical
>>   for most conditional branches to be naturally based on comparisons
>>   against 0 resulting from the immediately preceding operation, which
>>   would have otherwise not required an explicit compare?)
> 
> I think that it's not good.

- although I agree that there's likely a cleaner more consistent way to
  accurately describe and track condition-code side-effects of AVR's ISA,
  it seems that this approach actually inhibits GCC helping to optimize
  the code, as too much information is being hidden from it? For example:

  It seems that by relying on peephole optimization to try to eliminate
  otherwise redundant explicit expensive comparison operations on wider
  than byte sized operands which were generated because multi-byte wide
  operations don't expose their cc-mode side-effects, may not be a good
  strategy?

  As it would seem that the initial hiding of this critical information
  only inhibits GCC from being able to optimally (not to mention safely)
  schedule basic block instruction sequences in an effort to eliminate
  the necessity of otherwise relatively expensive multi-byte comparisons
  to begin with. (Which would seem to be more optimal than relying on
  no scheduling, and likely only catching some of the potential
  opportunities to eliminate expensive compares after the fact?)

(however acknowledge that may misunderstand GCC's instruction scheduling
 capabilities, and/or be missing something more significant?)

Thanks, -paul-