d的整4乘法

原文

LDC,GDC和DMD在实现int4的乘法方面不同.

//------ test-case.d ---------

import core.simd;

int4 mul_4_ints (int4 a, int4 b)
{
    return a * b; // LDC和GDC正常,但`DMD`不正常
}

高效的int4*int4要求Neon或SSE4.1,及:
1,DMD不实现int4*int4.
2,GDC和LDC用替换序列和两条乘法指令实现了它,GDC有该算法.

在intel内部,我现在告诉人们使用_mm_mullo_epi32来保持可移植性,它会变通,因为该操作有类似可移植性陷阱.

两个解决方法:
1,从LDC和GDC中删除支持,因为在SSE4.1以下没有指定硬件支持.用户被迫考虑可移植性.
2,在DMD中添加对int4*int4的支持,以匹配功能.用户可用core.simd而不会担心破坏兼容性.
我不知道什么是最好的,需要带有pmulld指令的Neon或SSE4.1.

对DMD,编译时需要显式传递-mcpu=avx,它在编译时,对给定类型模式,在DMD后端中,使用严格门来确定式是否映射到单个操作码.

即使信息在那且可分别查询GCC或LLVM,GDC和LDC也忽略了该门.并且只是许可性允许操作,这确实表明,当向下传递到后端时,当编译目标没有可用的操作码时,它可能会把操作向量拆分为更窄的模式.

该行为是合理的,因为严格地说,不知道优化器是否会按有支持的操作码来重新写式.
如:'a/b'没有向量操作,但'a>>b'有.

在gdc-13中,默认'-Wvector-operation-performance'是打开的,因此至少会收到在窄模式下扩展式的非阻塞警告.

DMD的该行为与设计一致.(如果使用-mcpu=avx开关,它工作)
变通方案比本地指令慢得多.用户可能没有发现变通方案的慢.通知用户没有针对它的本地指令,用户然后可故意地选择最适合他的指定应用的变通方案.
特别,用户可能不需要本地指令的全部能力,所以用完整语义是负优化,或可选择不要求丢失的本地指令的不同算法.

该行为是马努请求的,他花了大量时间编写高性能向量代码.
GDC和LDC对此有不同的哲学,这是他们的特权.
因此,我把它标记为无效,因为行为是故意的,而不是漏洞.