Paul Schlie <[EMAIL PROTECTED]> writes:
> > 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)
As I know only scheduler can break cmp+jump.
AVR need not in any scheduling.
> >> (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?
I don't want to hide useful information. I want to ignore unusable.
For example: even i386 port (probably better port) isn't
"accurately describe and track condition-code side-effects"
Look at *addsi_1:
(define_insn "*addsi_1"
[(set (match_operand:SI 0 "nonimmediate_operand" "=r,rm,r")
(plus:SI (match_operand:SI 1 "nonimmediate_operand" "%0,0,r")
(match_operand:SI 2 "general_operand" "rmni,rni,lni")))
(clobber (reg:CC FLAGS_REG))]
"ix86_binary_operator_ok (PLUS, SImode, operands)"
FLAGS_REG just clobbered. It's not a true.
As I understand '(clobber (reg:CC FLAGS_REG))' needed only for
scheduling.
AVR havn't scheduling and I want to omit such clobbers, but I have
added special insns for optimization.
For example:
(define_insn "*subqi_3"
[(set (reg CC_REGNUM)
(compare (match_operand:QI 1 "register_operand" "0,0")
(match_operand:QI 2 "nonmemory_operand" "r,i")))
(set (match_operand:QI 0 "nonimmediate_operand" "=r,d")
(minus:QI (match_dup 1) (match_dup 2)))]
"avr_match_ccmode (insn, CC_ZNmode)"
> 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?
I'm agree that may be better to split HImode comparision to
two QImode comparisions, but it's a next step. For this step you not
needed to change something outside HImode comparision.
>
> 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?)
Ohhh. I'm probably understand you. Are you mean that better way for
splitting comparisions is
cmpHI, cbranch -> cmpQI1_and_set_CC, cbranch1, cmpQI2_and_use_CC, cbranch2 ?
In this case cmpQI1,cbranch1 may be in one basic block
and cmpQI2, cbranch2 in another. You right it's impossible without
"accurately describe and track condition-code side-effects".
If you (or any other) want to support such splitting then clobbers
must be added to insns.
I think that better to support
cmpHI, cbranch -> cmpQI1_set_CC, cmpQI2_use_CC, cbranch.
because AVR is a microcontroller and code size more important than code speed.
Denis.
