[LLVMdev] Use of 'ldrd' instructions with unaligned addresses on armv7 (Major bug in LLVM optimizer?)

[Esperanza de Escobar]

No one is arguing that there aren't ABI specs or LLVM design
guidelines that say that unaligned accesses "should not", "could not"
or "aren't guaranteed to" work, because it's besides the point.

The point is that unaligned 32-bit loads and stores *work in practice*
on every single ARM device Apple has ever manufactured. I'm not a
hardware person, but I'm guessing it takes a non-negligible amount of
silicon to support them. With Xcode's switch to LLVM, this deployed
silicon has suddenly become off-limits because of a single overzealous
optimization. The only possible workarounds are assembly code and
turning the optimizer off altogether.

It would be one thing if the optimizer generated ldrd/strd for 64-bit
loads and stores only. But it actually goes as far as taking two
separate 32-bit accesses and merging them into one
silently-incompatible 64-bit access. These two accesses could be
unrelated to one another in the context of the code at hand, and even
syntactically distant.

This introduces a stealth crash into Apple-only code that was bug-free
under gcc. And realizing what's going on requires familiarity with ARM
assembly. With a bit of googling you'll find other support board posts
asking "Why is my code suddenly crashing after upgrading Xcode?"

Unfortunately, there is no way to turn this optimization off. Not to
mention that it's not much of an optimization at all. I'd be surprised
if you could measure a performance improvement on a real-world program
with less than a million iterations, maybe orders more.

You can measure its damage pretty significantly, though. We've already
spent a lot of hours tracking down unaligned accesses and wrapping
them in assembly macros. Which of course ends up disabling other,
actually useful optimizations. And with a large codebase, we can't be
sure we've found every last one yet.

Whether this optimization is academically acceptable or not, its net
impact in real-world terms is exceedingly negative.

EdE

On 1/24/12, David Blaikie <dblaikie at gmail.com> wrote:
>> Note that this code compiled with GCC 4.2 runs perfectly whereas LLVM will
>> produce a binary that crashes: LLVM breaks existing source code.
>
> On this point:
> This is not uncommon - and the very nature of "Undefined Behaviour".
> This reason alone is not enough to justify a change to Clang. We/you
> would need to show that the behaviour is defined & Clang is violating
> that definition.
>
> Chris has posted about the general principle at length starting here:
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>