And the last one.
Maybe it is better to use the separate CC modes for individual status bits, to reflect all status changes? For example
I could define a CCZ mode for "zero" status bit, CCM mode for a "minus" status bit, and CCV mode for an "overflow" status bit. And then use a parallel of CC setters, like:
(parallel [
(set (reg:CCZ ST0_REGNO) (eq:HI (match_operand:HI 0 "register_operand" "") (const_int 0)))
(set (reg:CCM ST0_REGNO) (lt:HI (match_dup 0) (const_int 0)))
(set (reg:CCV ST0_REGNO) (gt:HI (match_dup 0) (const_int 65535)))
]
)
And then the compiler could test CC reg for branch or conditional insns in any of defined above modes to check whether a corresponding bit is set or not?
Thanks again. Dmitry.
--- Исходное сообщение ---
От кого: "Ian Lance Taylor" <iant@xxxxxxxxxx>
Кому: "Dmitry" <mittie@xxxxxxx>
Дата: 4 мая 2011, 20:11:44
Тема: Re: Back end question.
> "Dmitry" <mittie@xxxxxxx> writes:
>
> > First. How can I set a CC reg in a single CC mode with zero sign and overflow bits?
> > Zero and sign could be set with the pattern like this:
> > (set (reg:CCNZ ST0_REGNO)(compare:CCNZ (match_operand:HI 0 "register_operand" "") (const_int 0)))
> > But the overflow bit I think could be computed like (for HImode):
> > (set (reg:CCNZV ST0_REGNO)(compare:CCNZV (match_operand:HI 0 "register_operand" "") (const_int 65535)))
> > But how this two patterns could be merged in one, to set a CC reg in a single CC mode?
>
> That would require a peephole of some sort, I suppose.
>
> > And the second question. You said "try to clean up unnecessary test instructions afterward". How could I do so? Maybe with peephole optimizations? I mean do I need to search in peepholes for move-test-branch sequences, and if those moves involves accumulators as destinations, and tests operate with those accumulators, I should remove those tests?
>
> Yes.
>
> Or you might have to do in the machine_reorg pass.
>
> Ian
>
>
