e817966718
When we'd originally added unaligned-scalar-mem and unaligned-vector-mem, they were separated into two parts under the theory that some processor might implement one, but not the other. At the moment, we don't have evidence of such a processor. The C/C++ level interface, and the clang driver command lines have settled on a single unaligned flag which indicates both scalar and vector support unaligned. Given that, let's remove the test matrix complexity for a set of configurations which don't appear useful. Given these are internal feature names, I don't think we need to provide any forward compatibility. Anyone disagree? Note: The immediate trigger for this patch was finding another case where the unaligned-vector-mem wasn't being properly serialized to IR from clang which resulted in problems reproducing assembly from clang's -emit-llvm feature. Instead of fixing this, I decided getting rid of the complexity was the better approach.
22 lines
721 B
LLVM
22 lines
721 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=riscv32 | FileCheck %s
|
|
; RUN: llc < %s -mtriple=riscv32 -mattr=+fast-unaligned-access | FileCheck %s
|
|
|
|
define void @foo_set(ptr nocapture noundef %a, i32 noundef %v) {
|
|
; CHECK-LABEL: foo_set:
|
|
; CHECK: # %bb.0: # %entry
|
|
; CHECK-NEXT: srli a2, a1, 8
|
|
; CHECK-NEXT: sb a1, 3(a0)
|
|
; CHECK-NEXT: sb a2, 4(a0)
|
|
; CHECK-NEXT: ret
|
|
entry:
|
|
%bf.load = load i96, ptr %a, align 1
|
|
%0 = and i32 %v, 65535
|
|
%bf.value = zext i32 %0 to i96
|
|
%bf.shl = shl nuw nsw i96 %bf.value, 24
|
|
%bf.clear = and i96 %bf.load, -1099494850561
|
|
%bf.set = or i96 %bf.clear, %bf.shl
|
|
store i96 %bf.set, ptr %a, align 1
|
|
ret void
|
|
}
|