将64位整数中的压缩8位整数并行减1，SWAR不带硬件SIMD

如果我有一个64位整数，那么我会将其解释为具有8个元素的打包8位整数数组。我需要1在处理溢出时从每个压缩整数中减去常数，而一个元素的结果不会影响另一个元素的结果。

我现在有这段代码，它可以工作，但是我需要一个解决方案，它可以并行地对每个压缩的8位整数进行减法，并且不进行内存访问。在x86上，我可以使用类似的SIMD指令psubb，以并行方式减去打包的8位整数，但是我正在编码的平台不支持SIMD指令。（在这种情况下为RISC-V）。

因此，我正在尝试执行SWAR（寄存器中的SIMD）以手动取消a的字节之间的进位传播uint64_t，从而执行以下操作：

uint64_t sub(uint64_t arg) {
    uint8_t* packed = (uint8_t*) &arg;

    for (size_t i = 0; i < sizeof(uint64_t); ++i) {
        packed[i] -= 1;
    }

    return arg;
}

我认为您可以使用按位运算符来执行此操作，但我不确定。我正在寻找不使用SIMD指令的解决方案。我正在寻找一种可移植的C或C ++解决方案，或者只是其背后的理论，以便我可以实现自己的解决方案。

如果您的CPU带有有效的SIMD指令，那么SSE / MMX paddb（_mm_add_epi8）也是可行的。彼得·科德斯（Peter Cordes）的答案还描述了GNU C（gcc / clang）矢量语法以及严格别名UB的安全性。我也强烈建议您也要复习该答案。

自己与做uint64_t是完全可移植的，但仍需要注意避免对准问题和访问时严格走样UB uint8_t一个阵列uint64_t*。您uint64_t已经通过从一个数据开始就把那部分排除在了问题之外，但是对于GNU C，一个may_aliastypedef解决了这个问题（有关此内容，请参见Peter的答案memcpy）。

否则，您可以将数据分配/声明为，uint64_t并uint8_t*在需要单个字节时通过进行访问。 unsigned char*允许为任何东西加上别名，以便针对8位元素的特定情况回避问题。（如果uint8_t根本存在，则可以假定它是一个unsigned char。）

请注意，这是对先前不正确算法的更改（请参阅修订历史记录）。

这是可能的，无需循环进行任意减法，并且对于1每个字节中的已知常量，效率更高。 主要技巧是通过设置高位来防止每个字节的进位，然后校正减法结果。

我们将稍微优化此处给出的减法技术。他们定义：

SWAR sub z = x - y
    z = ((x | H) - (y &~H)) ^ ((x ^~y) & H)

与H定义为0x8080808080808080U（即每个打包整数的MSB）。递减y为0x0101010101010101U。

我们知道它的y所有MSB都已清除，因此我们可以跳过其中一个掩码步骤（即y & ~H与y我们的情况相同）。计算过程如下：

1. 我们将的每个组件的MSB设置x为1，这样借位就不会传播通过MSB到达下一个组件。称此为调整后的输入。
2. 通过0x01010101010101从校正后的输入中减去，我们从每个分量中减去1 。由于步骤1，这不会导致组件间的借用。将其称为调整后的输出。
3. 现在，我们需要更正结果的MSB。我们将调整后的输出与原始输入的反向MSB进行异或运算，以完成结果的固定。

该操作可以写为：

#define U64MASK 0x0101010101010101U
#define MSBON 0x8080808080808080U
uint64_t decEach(uint64_t i){
      return ((i | MSBON) - U64MASK) ^ ((i ^ MSBON) & MSBON);
}

最好由编译器内联（使用编译器指令强制执行此操作），或者将该表达式作为另一个函数的一部分内联编写。

测试用例：

in:  0000000000000000
out: ffffffffffffffff

in:  f200000015000013
out: f1ffffff14ffff12

in:  0000000000000100
out: ffffffffffff00ff

in:  808080807f7f7f7f
out: 7f7f7f7f7e7e7e7e

in:  0101010101010101
out: 0000000000000000

性能细节

这是该函数的单次调用的x86_64程序集。为了获得更好的性能，应该内联在一起，希望这些常数可以尽可能长地存在于寄存器中。在常量存放在寄存器中的紧密循环中，实际的减量需要执行5条指令：优化后的or + not + and + add + xor。我看不到有其他方法可以胜过编译器的优化。

uint64t[rax] decEach(rcx):
    movabs  rcx, -9187201950435737472
    mov     rdx, rdi
    or      rdx, rcx
    movabs  rax, -72340172838076673
    add     rax, rdx
    and     rdi, rcx
    xor     rdi, rcx
    xor     rax, rdi
    ret

通过以下片段的一些IACA测试：

// Repeat the SWAR dec in a loop as a microbenchmark
uint64_t perftest(uint64_t dummyArg){
    uint64_t dummyCounter = 0;
    uint64_t i = 0x74656a6d27080100U; // another dummy value.
    while(i ^ dummyArg) {
        IACA_START
        uint64_t naive = i - U64MASK;
        i = naive + ((i ^ naive ^ U64MASK) & U64MASK);
        dummyCounter++;
    }
    IACA_END
    return dummyCounter;
}

我们可以证明，在Skylake机器上，每次迭代只需不到5个周期即可执行减量，异或和比较+跳转：

Throughput Analysis Report
--------------------------
Block Throughput: 4.96 Cycles       Throughput Bottleneck: Backend
Loop Count:  26
Port Binding In Cycles Per Iteration:
--------------------------------------------------------------------------------------------------
|  Port  |   0   -  DV   |   1   |   2   -  D    |   3   -  D    |   4   |   5   |   6   |   7   |
--------------------------------------------------------------------------------------------------
| Cycles |  1.5     0.0  |  1.5  |  0.0     0.0  |  0.0     0.0  |  0.0  |  1.5  |  1.5  |  0.0  |
--------------------------------------------------------------------------------------------------

（当然，在x86-64上，您只需要加载或movq将其加载到XMM reg中paddb，因此，看看它如何为RISC-V之类的ISA编译可能会更有趣。）

对于RISC-V，您可能正在使用GCC / clang。

有趣的事实：GCC知道其中一些SWAR bithack技巧（在其他答案中显示），并且在使用GNU C本机向量为没有硬件SIMD指令的目标编译代码时，可以使用它们。（但是RISC-V的clang只会天真地将其展开为标量运算，因此，如果您希望跨编译器具有良好的性能，则必须自己进行操作）。

本机向量语法的一个优点是，当针对具有硬件SIMD 的计算机时，它将使用该向量，而不是自动向量化您的bithack或类似的恐怖内容。

它使编写vector -= scalar操作变得容易。语法Just Works，也为您隐式广播标量。

另请注意，uint64_t*来自uint8_t array[]严格别名UB 的负载，因此要小心。（另请参见为什么要快速运行glibc的原因如此复杂？ re：在纯C语言中使SWAR bithacks严格混叠是安全的）。您可能希望这样声明一个uint64_t可以指针广播以访问任何其他对象的对象，例如char*ISO C / C ++中的工作方式。

使用这些将uint8_t数据转换为uint64_t以便与其他答案一起使用：

// GNU C: gcc/clang/ICC but not MSVC
typedef uint64_t  aliasing_u64 __attribute__((may_alias));  // still requires alignment
typedef uint64_t  aliasing_unaligned_u64 __attribute__((may_alias, aligned(1)));

进行锯齿安全加载的另一种方法是使用memcpy到中uint64_t，这也消除了alignof(uint64_t对齐要求。但是在没有有效未对齐负载的ISA上，当gcc / clang memcpy无法证明指针对齐时，它们不会内联和优化，这对于性能而言将是灾难性的。

TL：DR：最​​好的选择是将您的数据声明为uint64_t array[...]或动态地将其分配为uint64_t，或者最好alignas(16) uint64_t array[]; 确保至少与8个字节对齐；如果指定，则确保为16个字节alignas。

由于uint8_t几乎可以肯定unsigned char*，访问一个过uint64_t孔的字节是安全的uint8_t*（但对于uint8_t数组则相反）。因此，对于这种窄元素类型为的特殊情况unsigned char，您可以回避严格混叠问题，因为它char很特殊。

GNU C本机矢量语法示例：

始终允许GNU C本机向量使用其基础类型进行别名（例如，int __attribute__((vector_size(16)))可以安全地别名，int但不能float或uint8_t其他任何别名。

#include <stdint.h>
#include <stddef.h>

// assumes array is 16-byte aligned
void dec_mem_gnu(uint8_t *array) {
    typedef uint8_t v16u8 __attribute__ ((vector_size (16), may_alias));
    v16u8 *vecs = (v16u8*) array;
    vecs[0] -= 1;
    vecs[1] -= 1;   // can be done in a loop.
}

对于没有任何硬件SIMD的RISC-V，您可以使用它vector_size(8)来表达您可以有效使用的粒度，并执行两倍于较小向量的操作。

但是vector_size(8)对于同时使用GCC和clang的x86来说，编译起来非常愚蠢：GCC在GP整数寄存器中使用SWAR bithack，将clang解压缩为2个字节的元素以填充16个字节的XMM寄存器，然后重新打包。（MMX已过时，以至于GCC / clang甚至都不会使用它，至少对于x86-64来说不是这样。）

但随着vector_size (16)（Godbolt），我们得到预期的movdqa/ paddb。（使用生成的全矢量pcmpeqd same,same）。由于-march=skylake我们仍然得到两个单独的XMM ops而不是一个YMM，因此不幸的是，当前的编译器也不会将矢量ops“自动矢量化”为更宽的矢量：/

对于AArch64，使用起来还不错vector_size(8)（Godbolt）；ARM / AArch64可以使用d或q寄存器以8或16字节的块形式进行本地工作。

因此vector_size(16)，如果您希望在x86，RISC-V，ARM / AArch64和POWER上具有可移植的性能，则可能需要实际进行编译。但是，其他一些ISA在64位整数寄存器中执行SIMD，例如我认为的MIPS MSA。

vector_size(8)使查看asm更加容易（只有一个寄存器值的数据）：Godbolt编译器资源管理器

# GCC8.2 -O3 for RISC-V for vector_size(8) and only one vector

dec_mem_gnu(unsigned char*):
        lui     a4,%hi(.LC1)           # generate address for static constants.
        ld      a5,0(a0)                 # a5 = load from function arg
        ld      a3,%lo(.LC1)(a4)       # a3 = 0x7F7F7F7F7F7F7F7F
        lui     a2,%hi(.LC0)
        ld      a2,%lo(.LC0)(a2)       # a2 = 0x8080808080808080
                             # above here can be hoisted out of loops
        not     a4,a5                  # nx = ~x
        and     a5,a5,a3               # x &= 0x7f... clear high bit
        and     a4,a4,a2               # nx = (~x) & 0x80... inverse high bit isolated
        add     a5,a5,a3               # x += 0x7f...   (128-1)
        xor     a5,a4,a5               # x ^= nx  restore high bit or something.

        sd      a5,0(a0)               # store the result
        ret

我认为这是与其他非循环答案相同的基本思想；防止进位，然后修正结果。

这是5条ALU指令，比我认为的最高答案差。但是看起来关键路径延迟只有3个周期，两条链的2条指令各自导致XOR。@Reinstate Monica-ζ--的答案编译为一个4周期的dep链（对于x86）。通过sub在关键路径上包含朴素的内容，可以使5周期循环的吞吐量成为瓶颈，而循环确实使延迟成为瓶颈。

但是，这对clang没有用。它甚至没有按加载时的顺序添加和存储，因此它甚至没有做好软件流水线工作！

# RISC-V clang (trunk) -O3
dec_mem_gnu(unsigned char*):
        lb      a6, 7(a0)
        lb      a7, 6(a0)
        lb      t0, 5(a0)
...
        addi    t1, a5, -1
        addi    t2, a1, -1
        addi    t3, a2, -1
...
        sb      a2, 7(a0)
        sb      a1, 6(a0)
        sb      a5, 5(a0)
...
        ret

我要指出的是，一旦您开始处理多个uint64_t，您编写的代码实际上就会矢量化。

https://godbolt.org/z/J9DRzd

您可以确保减法不会溢出，然后修复高位：

uint64_t sub(uint64_t arg) {
    uint64_t x1 = arg | 0x80808080808080;
    uint64_t x2 = ~arg & 0x80808080808080;
    // or uint64_t x2 = arg ^ x1; to save one instruction if you don't have an andnot instruction
    return (x1 - 0x101010101010101) ^ x2;
}

不知道这是否是您想要的，但是它会并行执行8个减法：

#include <cstdint>

constexpr uint64_t mask = 0x0101010101010101;

uint64_t sub(uint64_t arg) {
    uint64_t mask_cp = mask;
    for(auto i = 0; i < 8 && mask_cp; ++i) {
        uint64_t new_mask = (arg & mask_cp) ^ mask_cp;
        arg = arg ^ mask_cp;
        mask_cp = new_mask << 1;
    }
    return arg;
}

说明：位掩码以每个8位数字中的1开头。我们将其与我们的论点异或。如果我们在该位置有1，则减去1，然后必须停止。这是通过将new_mask中的相应位设置为0来完成的。如果我们有一个0，我们将其设置为1，并且必须进行进位，因此该位保持为1，然后将掩码向左移动。我认为，您最好自己检查一下新面罩的生成是否按预期工作，但是第二点意见也不错。

PS：我实际上不确定mask_cp循环中不为null 的检查是否会减慢程序速度。没有它，代码将仍然是正确的（因为0掩码什么都不做），并且编译器执行循环展开会容易得多。

int subtractone(int x) 
{
    int f = 1; 

    // Flip all the set bits until we find a 1 at position y
    while (!(x & f)) { 
        x = x^f; 
        f <<= 1; 
    } 

    return x^f; // return answer but remember to flip the 1 at y
} 

您可以使用上述方法通过按位运算来完成此操作，而您只需要将整数分成8位，就可以向该函数发送8次。以下部分摘自如何将64位数字拆分为八个8位值？我添加上面的功能

uint64_t v= _64bitVariable;
uint8_t i=0,parts[8]={0};
do parts[i++] = subtractone(v&0xFF); while (v>>=8);

无论有人如何遇到，它都是有效的C或C ++

不会尝试提出代码，但是如果要递减1，则可以按8个1递减一组，然后检查以确保结果的LSB已“翻转”。任何未切换的LSB都表明在相邻的8位中发生了进位。应该有可能计算出一系列AND / OR / XOR，而无需任何分支。

将工作完全集中在每个字节上，然后放回原处。

uint64_t sub(uint64_t arg) {
   uint64_t res = 0;

   for (int i = 0; i < 64; i+=8) 
     res += ((arg >> i) - 1 & 0xFFU) << i;

    return res;
   }