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: Paul Schlie
Subject: Re: AW: AW: [avr-libc-dev] Additional instruction patterns for or more efficient code using mixed QI/HI/SI expressions
Date: Mon, 13 Dec 2004 19:40:33 -0500
User-agent: Microsoft-Entourage/11.1.0.040913

> From: Björn Haase <address@hidden>
>> 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")
>
> 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.

After toying with a similar notion, for good or bad (right or wrong?) I've
personally come to the conclusion that DI mode operands and corresponding
operations are likely of too little value in typical AVR applications to
require much if any effort; concluding (as it seemed you had initially),
that improving the cycle/register/memory efficiency of typical 8/16 bit
operand/operations are of likely greatest value, followed by the occasional
requirement for 32 bit operand/operations.

If this can be accomplished, I don't personally don't think anyone would
typically care about 64 bit operands and/or operations; as if they were
truly required, another processor/platform would likely be a better choice
for the corresponding product/project

So wonder if first experimenting initially with implementing SI/HI mode ops
with this method might be more practically useful, and easier to determine
if the approach is beneficial relative to the present implementation as a
base-line.







reply via email to

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