[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
- Re: AW: AW: [avr-libc-dev] Additional instruction patterns for or more efficient code using mixed QI/HI/SI expressions,
Björn Haase <=