[llvm] r181944 - Revert "Support unaligned load/store on more ARM targets"
Derek Schuff
dschuff at google.com
Wed May 15 16:07:44 PDT 2013
Author: dschuff
Date: Wed May 15 18:07:43 2013
New Revision: 181944
URL: http://llvm.org/viewvc/llvm-project?rev=181944&view=rev
Log:
Revert "Support unaligned load/store on more ARM targets"
This reverts r181898.
Modified:
llvm/trunk/lib/Target/ARM/ARMSubtarget.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMSubtarget.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMSubtarget.cpp?rev=181944&r1=181943&r2=181944&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMSubtarget.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMSubtarget.cpp Wed May 15 18:07:43 2013
@@ -162,23 +162,10 @@ void ARMSubtarget::resetSubtargetFeature
if (!isThumb() || hasThumb2())
PostRAScheduler = true;
- if (!StrictAlign) {
- // Assume pre-ARMv6 doesn't support unaligned accesses.
- //
- // ARMv6 may or may not support unaligned accesses depending on the
- // SCTLR.U bit, which is architecture-specific. We assume ARMv6
- // Darwin targets support unaligned accesses, and others don't.
- //
- // ARMv7 always has SCTLR.U set to 1, but it has a new SCTLR.A bit
- // which raises an alignment fault on unaligned accesses. Linux
- // defaults this bit to 0 and handles it as a system-wide (not
- // per-process) setting. It is therefore safe to assume that ARMv7+
- // targets support unaligned accesses.
- //
- // The above behavior is consistent with GCC.
- if (hasV7Ops() || (hasV6Ops() && isTargetDarwin()))
- AllowsUnalignedMem = true;
- }
+ // v6+ may or may not support unaligned mem access depending on the system
+ // configuration.
+ if (!StrictAlign && hasV6Ops() && isTargetDarwin())
+ AllowsUnalignedMem = true;
// NEON f32 ops are non-IEEE 754 compliant. Darwin is ok with it by default.
uint64_t Bits = getFeatureBits();
More information about the llvm-commits
mailing list