Re: Back end question.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks a lot Ian for your help.
The last two questions.
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?

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?

Thanks again.
Dmitry.

--- Исходное сообщение ---
 От кого: "Ian Lance Taylor" <iant@xxxxxxxxxx> 
 Кому: "Dmitry" <mittie@xxxxxxx> 
 Дата: 4 мая 2011, 18:31:43 
 Тема: Re: Back end question. 
 


> "Dmitry" <mittie@xxxxxxx> writes:
> 
> > I read it many times, but still I don't get how can I set for example a zero bit a sign bit and for example an overflow bit in one CC mode. Or I need to write a parallel of CC sets for different status bits with different CC modes?
> 
> You can only use the condition code for a conditional branch or a
> conditionally executed instruction. The instruction is always going to
> know what conditions it is going to test. Your CC mode has to express
> which conditions are valid. Then the compiler knows that it can remove
> an explicit test instruction if the expression matches and the CC mode
> matches.
> 
> > And even so there's still a question if I replace a clobber with a CC set rtx in define_expand, and before reload the compiler uses that CC set, but after reload it turns out that the destination is not an accumulator, so there shouldn't be any CC set at all, how can I fix that?
> 
> You can't. Don't do that. You can replace a clobber with a pattern
> which sets the CC, but you can't do the otherwise. You need to use
> define_split to insert the CC setters when appropriate after reload, and
> then try to clean up unnecessary test instructions afterward.
> 
> Ian
> 
> > --- Исходное сообщение ---
> > От кого: "Ian Lance Taylor" <iant@xxxxxxxxxx> 
> > Кому: "Dmitry" <mittie@xxxxxxx> 
> > Дата: 4 мая 2011, 17:54:51 
> > Тема: Re: Back end question. 
> > 
> >
> >
> >> "Dmitry" <mittie@xxxxxxx> writes:
> >> 
> >> > I see. Ok let's say it this way. If I have an move instruction that if
> >> > a destination operand is an accumulator can set some status bits, like
> >> > zero or sign. How can I use this feature with the compiler? For
> >> > example, after "mov" to the accumulator the compiler could use the
> >> > status bits from that "mov" with the branch insn (without a seperate
> >> > compare).
> >> 
> >> You have to change the move instruction to be a PARALLEL of two SETS,
> >> one to set the destination register and one to set the status register.
> >> 
> >> It may help to read the "Condition Code Status" section in the internals
> >> manual.
> >> 
> >> Ian
> >> 
> >> > --- Исходное сообщение ---
> >> > От кого: "Ian Lance Taylor" <iant@xxxxxxxxxx> 
> >> > Кому: "Dmitry" <mittie@xxxxxxx> 
> >> > Дата: 4 мая 2011, 17:29:03 
> >> > Тема: Re: Back end question. 
> >> > 
> >> >
> >> >
> >> >> "Dmitry" <mittie@xxxxxxx> writes:
> >> >> 
> >> >> > Ok. But what if the compiler uses that unnecessary clobber for a
> >> >> > branch or another CC dependent insn before reload, and if I remove
> >> >> > that clobber in a define_split after reload, could I end up with a
> >> >> > corrupted code?
> >> >> 
> >> >> I'm sorry, I don't understand what you are trying to say. The compiler
> >> >> can't use a clobber. Simply removing a clobber can't cause corrupted
> >> >> code, because the compiler was already assuming that the value in the
> >> >> register was unpredictable.
> >> >> 
> >> >> Ian
> >> >> 
> >> >> > --- Исходное сообщение ---
> >> >> > От кого: "Ian Lance Taylor" <iant@xxxxxxxxxx> 
> >> >> > Кому: "Dmitry" <mittie@xxxxxxx> 
> >> >> > Дата: 29 апреля 2011, 19:52:44 
> >> >> > Тема: Re: Back end question. 
> >> >> > 
> >> >> >
> >> >> >
> >> >> >> "Dmitry" <mittie@xxxxxxx> writes:
> >> >> >> 
> >> >> >> > I have one more question. If I have, for example, a define_insn rtx which matches a pattern generated by previous define_expand rtx. define_expand and define_split combination produces either a simple "set" rtx or "set" plus clobber of CC reg. And if in define_insn I specify a constraint that requires such an operand type which should generate a CC clobber, but initially there could be a combination of operands that does not clobber a CC and also does not satisfy constraints, so compiler must reload one or two operands in appropriate registers which satisfies constraints. In the case those appropriate registers should clobber a CC does a compiler add a suitable clobber rtx as written in define_split, or it just changes the registers names without any knowledge of a necessary clobber?
> >> >> >> 
> >> >> >> If I understand your question correctly, then the compiler is not going
> >> >> >> to add a clobber. Reload does not change the shape of the instruction.
> >> >> >> It just shuffles registers to match the constraints. If you have
> >> >> >> constraints which require a clobber, then the insn pattern should have a
> >> >> >> clobber. You can use define_split to remove an unnecessary clobber
> >> >> >> after reload is complete.
> >> >> >> 
> >> >> >> Ian
> >> >> >> 
> >> >> >> 
> >> >> 
> >> >> 
> >> 
> >> 
> 
> 


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux