> From: Denis Chertykov <[EMAIL PROTECTED]> >> Paul Schlie <[EMAIL PROTECTED]> 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-
