llvm.org GIT mirror llvm / 6fc6319
Support unaligned load/store on more ARM targets This patch matches GCC behavior: the code used to only allow unaligned load/store on ARM for v6+ Darwin, it will now allow unaligned load/store for v6+ Darwin as well as for v7+ on other targets. The distinction is made because v6 doesn't guarantee support (but LLVM assumes that Apple controls hardware+kernel and therefore have conformant v6 CPUs), whereas v7 does provide this guarantee (and Linux behaves sanely). Overall this should slightly improve performance in most cases because of reduced I$ pressure. Patch by JF Bastien git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181897 91177308-0d34-0410-b5e6-96231b3b80d8 Derek Schuff 7 years ago
1 changed file(s) with 17 addition(s) and 4 deletion(s). Raw diff Collapse all Expand all
161161 if (!isThumb() || hasThumb2())
162162 PostRAScheduler = true;
164 // v6+ may or may not support unaligned mem access depending on the system
165 // configuration.
166 if (!StrictAlign && hasV6Ops() && isTargetDarwin())
167 AllowsUnalignedMem = true;
164 if (!StrictAlign) {
165 // Assume pre-ARMv6 doesn't support unaligned accesses.
166 //
167 // ARMv6 may or may not support unaligned accesses depending on the
168 // SCTLR.U bit, which is architecture-specific. We assume ARMv6
169 // Darwin targets support unaligned accesses, and others don't.
170 //
171 // ARMv7 always has SCTLR.U set to 1, but it has a new SCTLR.A bit
172 // which raises an alignment fault on unaligned accesses. Linux
173 // defaults this bit to 0 and handles it as a system-wide (not
174 // per-process) setting. It is therefore safe to assume that ARMv7+
175 // targets support unaligned accesses.
176 //
177 // The above behavior is consistent with GCC.
178 if (hasV7Ops() || (hasV6Ops() && isTargetDarwin()))
179 AllowsUnalignedMem = true;
180 }
169182 // NEON f32 ops are non-IEEE 754 compliant. Darwin is ok with it by default.
170183 uint64_t Bits = getFeatureBits();