On Tue, Oct 28, 2014 at 11:46 AM, Matthew Fortune <matthew.fort...@imgtec.com> wrote: >> >> > Do you have an objection to allowing an option to disable these >> >> instructions (despite the reason for wanting to do so)? >> >> >> >> Yes this seems like a bad workaround for broken code. >> >> >> > Well, we work around broken hardware all the time. What would you >> suggest that Steve do instead? >> >> We work around broken hardware all the time yes but that is something >> which is hard to change. Software is easier to fix. That does not >> mean in the compiler. The compiler team should not get themselves in >> the business of working around broken software that depends on >> undefined behavior (this undefined behavior is very obvious and easier >> to fix in the source of the problem). Report the bug to Google. > > I'm mostly in agreement with Andrew on this. I'd like to understand more > about the use-case and what happens for other architectures (only ARM > and x86 are really relevant here I guess). I believe x86 will just > happily load/store doubles to 4-byte aligned addresses but I'm not sure > for ARM. If ARM has to take unaligned access faults for this then I > think MIPS simply has to do the same.
On AArch32 (ARM) the equivalent general purpose instructions (ldrd / strd , vldr / vstr, vpush / vpop, vldm / vstm) require only 4 byte alignment in the architecture. The only case where we may have a problem is with ldrexd / strexd instructions which are used for atomics but I'm not sure if that is under question / discussion here. This is really an application "design / portability" issue rather than anything else. So, there's no need to take alignment faults on AArch32 in this situation. Oh and before someone asks AArch64 is not a strict alignment target and so the compiler is free to emit unaligned accesses unless it is told not to do so. regards Ramana
