Re: What is the best way to resolve ARM alignment issues for large modules?

Re: What is the best way to resolve ARM alignment issues for large modules?

[Andrew Haley]

On 05/07/2010 11:40 PM, Shaun Pinney wrote:
>
> Essentially, we have code which works fine on x86/PowerPC but fails on ARM due
> to differences in how misaligned accesses are handled.  The failures occur in
> multiple large modules developed outside of our team and we need to find a
> solution.  The best question to sum this up is, how can we use the compiler to
> arrive at a complete solution to quickly identify all code locations which
> generate misaligned accesses and/or prevent the compiler from generating
> misaligned accesses?  Thanks for any advice.  I'll go into more detail below.

Just to begin.  You are asking for help using gcc, and gcc@gcc.gnu.org
is for the development of gcc.  gcc-help@gcc.gnu.org is the right
place.

> We're using an ARM9 core (ARMv5) and notice that GCC generates
> misaligned load instructions for certain modules in our platform.
> For these modules, which work correctly on x86/PowerPC, the
> misaligned loads causes failures.  This is because the ARM rounds
> down misaligned addresses to the correct alignment, performs the
> memory load, and rotates the data before placing in a register.  As
> a result, a misaligned multi-byte load instruction on ARM actually
> loads memory below the requested address and does not load all upper
> bytes from "address" to "address + size - 1" so it appears to these
> modules as incorrect data.  On x86/PowerPC, loads do provide bytes
> from "address" to "address + size - 1" regardless of alignment, so
> there are no problems.
> 
> Fixing the code manually for ARM alignment has difficulties.  Due to
> the large code volume of these external modules, it is difficult to
> identify all locations which may be affected by misaligned accesses
> so the code can be rewritten.  Currently, the only way to detect
> these issues is to use -Wcast-align and view the output to get a
> list of potential alignment issues.  This appears to list a large
> number of false positives so sorting through and doing code
> investigation to locate true problems looks very time-consuming.

-Wcast-align will tell you where the problematic casts are, but in
general to solve your problem by static analysis sounds to me to be
uncomputable.

> On the runtime side, we've enabled alignment exceptions to catch
> some additional cases, but the problem is that exceptions are only
> thrown for running code.  There is always the chance there is some
> more unexecuted 'hidden' code waiting to fail when the right
> circumstance occurs.  I'd like to provably remove the problem
> entirely and quickly.
> 
> One idea, to guarantee no load/store alignment problems will affect
> our product, was to force the compiler to generate single byte
> load/store instructions in place of multi byte load/store
> instructions when the alignment cannot be verified by the compiler.

It all depends on what your program is doing.  If it is taking
character pointers and casting them to larger integer types, then the
compiler cannot see what is going on when such a pointer is passed to
a separately compiled function.  If you are passed an int* then you
have to believe that it really is an int* and not something else.

I am also very worried that such casts my be undefined behaviour and
cause code generation problems elsewhere.  It might well be that the
misaligned accesses you are seeing are just the tip of the iceberg.

I'd recommend -fno-strict-aliasing.

> Such as, for pointer typecasts where the alignment is increased
> (e.g. char * to int *), accesses to misaligned fields of packed data
> structures, accesses to structure fields not allocated on the stack,
> etc.  Is this available?  Obviously, this will add performance
> overhead, but would clearly resolve the issue for affected modules.

gcc can already handle packed structures, so the code generation
problem for that is solved.

The question is: just how much of a performance hit are you prepared
to take?  Will you accept that every access via a pointer may be
misaligned, with all the performance consequences?

Andrew.