Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 22.214.171.124
strauman at slac.stanford.edu
Mon Dec 4 10:30:49 CST 2006
Peer Stritzinger wrote:
> On 11/28/06, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>> + It is an OPTIMIZATION and an optional one at that.
>> This isn't a test of manhood. There isn't any shame in
>> disabling it.
> And as a optimization it is even a trade-off namely a possible space -
> time tradeoff.
While the optimization is optional, programs that violate the
aliasing rule are unfortunately not C99 compliant - the
standard does *not* declare this rule optional, unfortunately.
> Code that breaks the strict-aliasing prerequsites is most times not
> written accidentally so but to conserve program and data memory at the
> expens of the compiler doing *possibly* more clever things with our
> Coding in a strict-aliasing compatible style usually means using
> different data structures
> and programming constructs that need more object code and/or more ram
> and more levels of pointer indirection.
> So it might be that overall performance of a changed RTEMS with strict-aliasing
> might be even worse than what we get by -fno-strict-aliasing
>> + I don't know how much benefit turning it on would have
>> anyway. In general, RTEMS proper is written to avoid unnecessary
>> memory references so this would probably not have big impact.
>> So how much performance gain could turning this on win anyway?
> When I looked at the PowerPC assembler code of the code that showed the problem
> comparing the versions with and without -fno-strict-aliasing:
> * The no strict aliasing code does two memory accesses more
> * These were exactly the two accesses that were wrongly optimized away.
>> + As Eric points out, other OSes with larger user and maintainer
>> bases have not found a solution to using this optimization
>> safely. There is a lot of code in RTEMS from BSD.
> Actually from my involvement with the BSD crowd, they are not even trying to
> avoid -fno-strict-aliasing since they probably are aware of the
> optimization tradeoff.
> If I look through the Ports Collection of FreeBSD -fno-strict-aliasing is set
> for many programs ... as it looks like all the Perl stuff is built like this.
>> To determine if this is a branch only or forever thing, one piece
>> of data we need is the impact of this option on the tmtests.
>> Assuming they all run on Peer's target hardware, we know
>> optimization is doing something there whether it is good or not. :)
> Can I help somehow running these tests?
> rtems-users mailing list
> rtems-users at rtems.com
More information about the rtems-users