On 12/01/2012 21:09, Weddington, Eric wrote:
-----Original Message-----
From: Georg-Johann Lay
Sent: Thursday, January 12, 2012 10:55 AM
To: Weddington, Eric
Cc: Joerg Wunsch; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs
areincorrect
sizeof(double) = 4 also breaks the standard...
Hence, one of the reasons to have correct doubles added to the backend.
<snip>
As said above, it's not only about optimization as such but also about
promotion rules that cannot be optimized away in all situation. So if
you
are
on a target were each byte counts I guess developers will very much
appreciate
-mint8, be it blessed by standard or not...
Hmm.
One of the biggest complaints from users has to do with promotion rules
being overly enforced during a set of operations, and then the result is
stored in some variable, typically of a smaller size (typically an
unsigned 8-bit variable), thereby truncating the value. In these
particular cases the enforcement of the promotion rules has no bearing
on the final outcome of the operations, but it does cause an unnecessary
increase in code size.
In these cases, is there a way to optimize the code such that these
promotion rules aren't strictly followed *when it does not affect the
outcome of the operation*?
The problem that I have with -mint8 is:
- it doesn't follow the standard
- it breaks avr-libc (or rather, avr-libc isn't adapted to it)
- people use it, because the backend hasn't been taught how to do the
right thing.
The thing is, is if the AVR backend knew how to optimize away these
superfluous promotions, then I really don't think that -mint8 would ever
really be needed. Why should a user have to specify a switch to get the
compiler to do the right thing?
How can we get to this point?
Here is a better question to ask - at what point do the advantages of
-mint8 in terms of code size and speed outweigh its disadvantages in
terms of broken code and compiler bugs, questionable avr-libc support (I
say "questionable" because there seem to be lots of questions about it),
compiler and library maintenance, etc.?
Most people who need -mint8 are generally working on very small devices,
with little or no library needs. They need a working compiler - but
they've got one. Changes in newer gcc versions will have little effect
on their usage.
Why not say -mint8 is dead? All that is really needed is to make sure
it is easy for people to get hold of older compiler/library sets for
when they need -mint8 support. This really means that Atmel should have
them on their website - a simple "toolchain archives" page with zip
files / tarballs of the toolchains (not these hideous installers) is all
that is needed.
Then "-mint8" can be marked "deprecated" in gcc 4.7, and removed in the
future.
As to improvements of 8-bit code, this really isn't an "-mint8" issue
that is relevant to "-mint8" users considering a switch. It's a general
avr-gcc issue for all normal avr-gcc users. My personal experience is
that avr-gcc has got better at this over the generations, though there
are still plenty of missed optimisation opportunities. Sometimes
peepholes can help (but as Johann says, these can't fix everything, and
lead to suboptimal register usage). But I am sure that it is better to
spend the time and effort there than on maintaining "-mint8" support.
mvh.,
David
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list