llvmbot
commented
2 months ago @llvm/issue-subscribers-backend-aarch64
Author: Niles Salter (Validark)
Consider the following code:
```zig
const std = @import("std");
export fn foo(indices: @Vector(16, u8)) @Vector(16, u8) {
const iota: [64]u8 = std.simd.iota(u8, 64); // counts from 0 to 63 inclusive
return tbl4(iota[0..16].*, iota[16..32].*, iota[32..48].*, iota[48..64].*, indices);
}
fn tbl4(table_part_1: @Vector(16, u8), table_part_2: @Vector(16, u8), table_part_3: @Vector(16, u8), table_part_4: @Vector(16, u8), indices: @Vector(16, u8)) @TypeOf(indices) {
return struct {
extern fn @"llvm.aarch64.neon.tbl4"(@TypeOf(table_part_1), @TypeOf(table_part_2), @TypeOf(table_part_3), @TypeOf(table_part_4), @TypeOf(indices)) @TypeOf(indices);
}.@"llvm.aarch64.neon.tbl4"(table_part_1, table_part_2, table_part_3, table_part_4, indices);
}
```
Here is the emit:
```asm
.LCPI0_0:
.byte 48
...
.byte 63
.LCPI0_1:
.byte 32
...
.byte 47
.LCPI0_2:
.byte 16
...
.byte 31
.LCPI0_3:
.byte 0
...
.byte 15
foo:
adrp x8, .LCPI0_0
ldr q4, [x8, :lo12:.LCPI0_0]
adrp x8, .LCPI0_1
ldr q3, [x8, :lo12:.LCPI0_1]
adrp x8, .LCPI0_2
ldr q2, [x8, :lo12:.LCPI0_2]
adrp x8, .LCPI0_3
ldr q1, [x8, :lo12:.LCPI0_3]
tbl v0.16b, { v1.16b, v2.16b, v3.16b, v4.16b }, v0.16b
ret
```
I am not sure if this is correct aarch64 assembly, but couldn't we have instead done this?
```asm
.LCPI0_0:
.byte 32
...
.byte 63
.LCPI0_1:
.byte 0
...
.byte 31
foo:
adrp x8, .LCPI0_0
ldp q3, q4, [x8, :lo12:.LCPI0_0]
adrp x8, .LCPI0_1
ldp q1, q2, [x8, :lo12:.LCPI0_1]
tbl v0.16b, { v1.16b, v2.16b, v3.16b, v4.16b }, v0.16b
ret
```
Or even this (if slightly higher latency is acceptable)?
```asm
.LCPI0_0:
.byte 0
.byte 16
.byte 32
.byte 48
... ; deinterlaced constants
foo:
adrp x8, .LCPI0_0
ld4 { v1.16b, v2.16b, v3.16b, v4.16b }, [x8, :lo12:.LCPI0_0]
tbl v0.16b, { v1.16b, v2.16b, v3.16b, v4.16b }, v0.16b
ret
```
(The particular constants used in this code is just for demonstration purposes. Obviously we could do better in this case, zeroing out numbers higher than 63, with a `cmhi` followed by a `bic`)
LLVM IR:
```llvm
define dso_local <16 x i8> @foo(<16 x i8> %0) local_unnamed_addr {
Entry:
%1 = tail call <16 x i8> @llvm.aarch64.neon.tbl4.v16i8(<16 x i8> <i8 0, i8 1, i8 2, i8 3, i8 4, i8 5, i8 6, i8 7, i8 8, i8 9, i8 10, i8 11, i8 12, i8 13, i8 14, i8 15>, <16 x i8> <i8 16, i8 17, i8 18, i8 19, i8 20, i8 21, i8 22, i8 23, i8 24, i8 25, i8 26, i8 27, i8 28, i8 29, i8 30, i8 31>, <16 x i8> <i8 32, i8 33, i8 34, i8 35, i8 36, i8 37, i8 38, i8 39, i8 40, i8 41, i8 42, i8 43, i8 44, i8 45, i8 46, i8 47>, <16 x i8> <i8 48, i8 49, i8 50, i8 51, i8 52, i8 53, i8 54, i8 55, i8 56, i8 57, i8 58, i8 59, i8 60, i8 61, i8 62, i8 63>, <16 x i8> %0)
ret <16 x i8> %1
}
declare void @llvm.dbg.value(metadata, metadata, metadata) #1
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
declare <16 x i8> @llvm.aarch64.neon.tbl4.v16i8(<16 x i8>, <16 x i8>, <16 x i8>, <16 x i8>, <16 x i8>) #2
```
[Godbolt link](https://godbolt.org/z/reWb6es59)
efriedma-quic
davemgreen
Validark
Consider the following code:
Here is the emit:
I am not sure if this is correct aarch64 assembly, but couldn't we have instead done this?
Or even this (if slightly higher latency is acceptable)?
(The particular constants used in this code is just for demonstration purposes. Obviously we could do better in this case, zeroing out numbers higher than 63, with a
cmhifollowed by abic)LLVM IR:
Godbolt link