mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 04:02:41 +01:00
185390d230
Summary: This relaxes an assertion inside SelectionDAGBuilder which is overly restrictive on targets which have no concept of alignment (such as AVR). In these architectures, all types are aligned to 8-bits. After this, LLVM will only assert that accesses are aligned on targets which actually require alignment. This patch follows from a discussion on llvm-dev a few months ago http://llvm.1065342.n5.nabble.com/llvm-dev-Unaligned-atomic-load-store-td112815.html Reviewers: bogner, nemanjai, joerg, efriedma Reviewed By: efriedma Subscribers: efriedma, cactus, llvm-commits Differential Revision: https://reviews.llvm.org/D39946 llvm-svn: 320243
20 lines
550 B
LLVM
20 lines
550 B
LLVM
; RUN: llc -mattr=addsubiw < %s -march=avr | FileCheck %s
|
|
|
|
; This verifies that the middle end can handle an unaligned atomic load.
|
|
;
|
|
; In the past, an assertion inside the SelectionDAGBuilder would always
|
|
; hit an assertion for unaligned loads and stores.
|
|
|
|
%AtomicI16 = type { %CellI16, [0 x i8] }
|
|
%CellI16 = type { i16, [0 x i8] }
|
|
|
|
; CHECK-LABEL: foo
|
|
; CHECK: ret
|
|
define void @foo(%AtomicI16* %self) {
|
|
start:
|
|
%a = getelementptr inbounds %AtomicI16, %AtomicI16* %self, i16 0, i32 0, i32 0
|
|
load atomic i16, i16* %a seq_cst, align 1
|
|
ret void
|
|
}
|
|
|