avr-libc-dev
[Top][All Lists]
Advanced

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

Re: AW: AW: [avr-libc-dev] Additional instruction patterns for or more e


From: Björn Haase
Subject: Re: AW: AW: [avr-libc-dev] Additional instruction patterns for or more efficient code using mixed QI/HI/SI expressions
Date: Tue, 14 Dec 2004 00:36:54 +0100

Denis Chertykov <address@hidden> schrieb am 13.12.04 13:48:51:
> First ! oly add and sub needed in borrow. xor,and,or,not,neg are very
> simple. You can start with one of them.
> 
> UNSPEC's is not required for this.
> 
> Look at arm port:
> 
> (define_insn_and_split "*arm_adddi3"
>   [(set (match_operand:DI          0 "s_register_operand" "=&r,&r")
>       (plus:DI (match_operand:DI 1 "s_register_operand" "%0, 0")
>                (match_operand:DI 2 "s_register_operand" "r,  0")))
>    (clobber (reg:CC CC_REGNUM))]
>   "TARGET_ARM && !TARGET_CIRRUS"
>   "#"
>   "TARGET_ARM && reload_completed"
>   [(parallel [(set (reg:CC_C CC_REGNUM)
>                  (compare:CC_C (plus:SI (match_dup 1) (match_dup 2))
>                                (match_dup 1)))
>             (set (match_dup 0) (plus:SI (match_dup 1) (match_dup 2)))])
>    (set (match_dup 3) (plus:SI (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0))
>                              (plus:SI (match_dup 4) (match_dup 5))))]
>   "
>   {
>     operands[3] = gen_highpart (SImode, operands[0]);
>     operands[0] = gen_lowpart (SImode, operands[0]);
>     operands[4] = gen_highpart (SImode, operands[1]);
>     operands[1] = gen_lowpart (SImode, operands[1]);
>     operands[5] = gen_highpart (SImode, operands[2]);
>     operands[2] = gen_lowpart (SImode, operands[2]);
>   }"
>   [(set_attr "conds" "clob")
>    (set_attr "length" "8")]
> )
> 
> 
> > 
> > So far, I, however thought that there is no easy way for teaching
> > the compiler to actually use them since this would require to get
> > rid of all objects with DI/SI and HI mode after the RTL generation
> > step.
> 
> I mean `splitting' as define_split not as define_expand.
> May be better to enable such splitters only after reload pass.
> 
> > I thought, that this would make it necessary to add a completely new
> > optimizer pass. For implementing this, one would need a deeper
> > knowledge of gcc interna than I have.
> 
> No special passes !
> 
> Denis.
> 

I will have a look at this method. I did not even know that there is something 
like

define_insn_and_split 

maybe, I have missed something within the gcc documentation. 

I'd like to suggest that before starting with a complete rework of the entire 
back-end that replaces the presently working and well-tested patterns with 
"splitting-type" instructions, one might start with implementing the DI modes 
with 
this method. This way, one possibly could gather experience with how to find an 
optimum solution for the problem for the HI and SI modes as well. 
And this way, one has the benefit of immediately adding useful functionality to 
gcc.

I will have to recheck the issue, but so far, I have the impression that when 
doing
the splitting *after* reload, one could mainly expect to have a more 
*beautiful* and a more 
consistend back-end. This would certainly help much maintaining the back-end. 
At 
the moment I, however, do not understand, how one could realize major 
improvements
of the code efficiency this way. I have the impression, e. g. when looking at 
the huge amount 
of work that has been done to optimize the shifting expressions within the 
present system), 
that the potential for improving in comparison to the present state is not very 
high.
But as I said, I will have to look at this more closely.


I'd thus like to suggest, so far, to work myself a bit on implementing DI mode 
operations first,
with your suggested splitting method and I will report on what comes out. That 
will probably 
take a few weeks.
Since I probably will be forced to concentrate again on the good old HC08 
family or maybe a new 
Renesas controller within the next weeks, I do not want yet to start helping 
with a major work 
that I possibly could never finish:
ATMEL presently has design-in-freeze status within our company division because 
of serious HW bugs 
within the ATMEGA169 that Atmel seems not to be willing to fix, and because of 
some commercial 
issues due to differences between controller prices communicated by ATMEL and 
the final prices 
that we obtain within the supplier chain in series use.

Concerning, the DI part I think, however, that I could succeed implementing 
this part even if I would
be forced to stop using AVR.

Yours,

Björn

_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192





reply via email to

[Prev in Thread] Current Thread [Next in Thread]