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

[Alexandre Colucci]

In practice all Apple hardwares support misaligned accesses for single-register loads and stores.
If a pointer is not aligned, LLVM should not use the double-register loads and stores. It should keep the two single-register loads instead of trying to optimize them as one unsupported double-register load.
Note that this code compiled with GCC 4.2 runs perfectly whereas LLVM will produce a binary that crashes: LLVM breaks existing source code.

Alexandre


> The problem is in your code, not the compiler.  You're casting an unaligned char* to an int*, even though an int* pointer must be 4-byte aligned in every ARM ABI that I've ever seen.
> 
> On Jan 23, 2012, at 6:14 AM, Alexandre Colucci wrote:
> 
>> Hi,
>> 
>> I think I discovered a major armv7 optimization bug in Clang. I create a simple test case which exhibits the issue.
>> When you compile the attached file for armv7 with optimizations turned on (O2, O3 or Os), the binary generated led to a crash.
>> The issue can't be reproduced when using GCC 4.2. It can't be reproduced with Clang when the optimization is turned off (O0).
>> This issue can be reproduced with Xcode 4.2.1 and Xcode 4.3 Developer Preview 3 (4E71d).
>> 
>> The LLVM optimizer coalesces two loads into an ARM 'ldrd' double-load instruction. Unfortunately, some ARM hardware platforms (including all of Apple's) support misaligned accesses for single-register loads and stores ('ldr' and 'str' instructions), but not for double-register loads and stores ('ldrd' and 'strd' instructions.).
>> On those platforms, the attached code triggers an address error when passed a misaligned address if it's compiled by LLVM with the optimizer enabled, but not if it's compiled by gcc, or by LLVM with the optimizer disabled.
>> At a minimum, there should be an option to disable the generation of 'ldrd' and 'strd', or the automatic coalescing of two loads that just happen to be nearby.
>> 
>> I haven't found any bugs similar in the LLVM bug database. It is a known issue? This looks like a major optimization issue.
>> 
>> Thanks,
>> Alexandre
>> 
>> <main.m>_______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
>