I've been going through the ChangeLog for the release and am having trouble justifying some of the changes brought in. In particular: * -fstrict-volatile-bitfields, which is more appropriate for bare metal/kernel code * Cortex-M4 support * C locale support in libstdc++-v3
The march/mcpu clean up is OK but marginal.
Our focus is time based performance on the Cortex-A series with an implied applications over kernel/bare metal. This is a very narrow view, but every non-performance line of code we bring in can also bring in a bug.
Any thoughts? For those who are looking at using our toolchain, is earlier access to other toolchain improvements interesting?
-- Michael
On 11/09/2010 02:51 PM, Michael Hope wrote:
Our focus is time based performance on the Cortex-A series with an implied applications over kernel/bare metal. This is a very narrow view, but every non-performance line of code we bring in can also bring in a bug.
Can we explain this criteria a little bit further? "time based performance on the Cortex-A series" is like a principle, rather than a criteria. IMO, criteria should be specific, like, 1. Speed is improved on certain benchmarks, like EEMBC and SPEC2000, on cortex-a9/8. This is the ideal situation, and of course, we backport it. 2. Speed should be improved as we understand that patch, but benchmarks result doesn't show any speed improvements. Shall we backport it? or backport it if we can find speed improvements on some benchmarks. 3. Speed is not improved, but size is reduced. We focus on speed, shall we backport? I personally inclined to backport it if it is easy to do.
What do you think?
On 09/11/10 06:51, Michael Hope wrote:
I've been going through the ChangeLog for the release and am having trouble justifying some of the changes brought in. In particular:
- -fstrict-volatile-bitfields, which is more appropriate for bare
metal/kernel code
- Cortex-M4 support
- C locale support in libstdc++-v3
These changes were brought in on the (secondary) principle of keeping Sourcery G++ and Linaro GCC as closely related as possible.
There are two main advantages to this policy:
1. Future merges are easier if the sources have not diverged.
2. Each toolchain benefits from the other's testing efforts.
This principle has been acknowledged from the beginning of this project.
Note: the two are *not* exactly the same - some patches that customize SG++ in ways that would not be acceptable upstream have been omitted - but they do not diverge to wildly.
Andrew
On 09.11.2010 14:05, Andrew Stubbs wrote:
On 09/11/10 06:51, Michael Hope wrote:
I've been going through the ChangeLog for the release and am having trouble justifying some of the changes brought in. In particular:
- -fstrict-volatile-bitfields, which is more appropriate for bare
metal/kernel code
- Cortex-M4 support
- C locale support in libstdc++-v3
These changes were brought in on the (secondary) principle of keeping Sourcery G++ and Linaro GCC as closely related as possible.
There are two main advantages to this policy:
Future merges are easier if the sources have not diverged.
Each toolchain benefits from the other's testing efforts.
This principle has been acknowledged from the beginning of this project.
Note: the two are *not* exactly the same - some patches that customize SG++ in ways that would not be acceptable upstream have been omitted - but they do not diverge to wildly.
The main disadvantage of this policy for 4.4 were build failures for some packages in Ubuntu, introduced by non ARM related changes compared to the FSF GCC. Linaro isn't tasked with *finding* these build issues, so this is extra work on the Ubuntu side. I don't see how the first two changes mentioned above could introduce the build failures, would have to look at the third issue. In general I would like to see a changed policy for future Linaro releases to be more strict with some user visible behavioural changes.
Matthias
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
Matthias Klose -
Michael Hope -
Yao Qi