brintos

brintos / llvm-project-archived public Read only

0
0
Text · 1.7 KiB · 62dbd61 Raw
46 lines · plain
1; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py2; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -mattr=avx512f | FileCheck %s3 4; The alignment of 16 causes type legalization to split this as 3 loads,5; v16f32, v4f32, and v4f32. This loads 24 elements, but the load is aligned6; to 16 bytes so this i safe. There was an issue with type legalization building7; the proper concat_vectors for this because the two v4f32s don't add up to8; v16f32 and require padding.9 10define <23 x float> @load23(ptr %p) {11; CHECK-LABEL: load23:12; CHECK:       # %bb.0:13; CHECK-NEXT:    movq %rdi, %rax14; CHECK-NEXT:    vmovups (%rsi), %zmm015; CHECK-NEXT:    vmovaps 64(%rsi), %xmm116; CHECK-NEXT:    vmovdqa 80(%rsi), %xmm217; CHECK-NEXT:    vextractps $2, %xmm2, 88(%rdi)18; CHECK-NEXT:    vmovq %xmm2, 80(%rdi)19; CHECK-NEXT:    vmovaps %xmm1, 64(%rdi)20; CHECK-NEXT:    vmovaps %zmm0, (%rdi)21; CHECK-NEXT:    vzeroupper22; CHECK-NEXT:    retq23  %t0 = load <23 x float>, ptr %p, align 1624  ret <23 x float> %t025}26 27; Same test as above with minimal alignment just to demonstrate the different28; codegen.29define <23 x float> @load23_align_1(ptr %p) {30; CHECK-LABEL: load23_align_1:31; CHECK:       # %bb.0:32; CHECK-NEXT:    movq %rdi, %rax33; CHECK-NEXT:    vmovups (%rsi), %zmm034; CHECK-NEXT:    vmovups 64(%rsi), %xmm135; CHECK-NEXT:    movq 80(%rsi), %rcx36; CHECK-NEXT:    vmovss {{.*#+}} xmm2 = mem[0],zero,zero,zero37; CHECK-NEXT:    vmovss %xmm2, 88(%rdi)38; CHECK-NEXT:    movq %rcx, 80(%rdi)39; CHECK-NEXT:    vmovaps %xmm1, 64(%rdi)40; CHECK-NEXT:    vmovaps %zmm0, (%rdi)41; CHECK-NEXT:    vzeroupper42; CHECK-NEXT:    retq43  %t0 = load <23 x float>, ptr %p, align 144  ret <23 x float> %t045}46