On 18 October 2011 02:45, bearophile <bearophileh...@lycos.com> wrote:
> I have asked for a rotate intrinsic in Phobos, but Walter has added a > rewrite rule instead, that turns D code to a rot. > Personal experience has shown me that it's easy to write the operation in a > slightly different way (like with signed instead of unsigned values) that > causes a missed optimization. So I prefer still something specific, like a > Phobos intrinsic, to explicitly ask for this operation to every present and > future D compiler, with no risk of mistakes. > I agree, an intrinsic that guarantees compiler support, or even an operator... ;) > *Predecated selection:* Float, vector, and often enough even int math can > > really benefit from using hardware select opcodes to avoid loads/stores. > In > > C there is no way to express this short of vendor specific intrinsics > again. > > I don't understand what you are asking here. Please show an example. > > There is an enhancement request that asks to support vector operations like > this too (some CPUs support something like this in hardware): > int[] a = [1,2,3,4]; > int[] b = [4,3,2,1]; > auto c = a[] > b[]; > assert(c == [false, false, true, true]); > > Are operations like this what you are asking for here? > by predicated selection, I mean, code that will select from 2 values based on some predicate... code that looks like this: float c = (some comparison) ? x : z; .. This has hardware support on many modern architectures to perform it branch free, particularly important on PowerPC and other RISC chips. The vector equivalent depends on generating mask vectors from various comparisons (essentially the same as the scalar versions, but it would be nice to standardise that detail with a strict api). Working something like this: a = {1,2,3,4} b = {4,3,2,1} m = maskLessThan(a, b); -> m == { true, true, false, false }; (usually expressed by integer 0 or -1) c = select(m, a, b); -> c == {1, 2, 2, 1} Now this is effectively identical to: float c = a < b ? a : b; but in SIMD, but there's no nice expression in the language to do this. The details are occasionally slightly different on different architectures, hence I'd like to see a standard predecated selection API of some form, which will allow use of hardware opcodes for float/int, and also mapping to SIMD cleanly. This might possibly branch off into another topic about SIMD support in D, which appears to be basically non-existent. One of the real problems is lack of definition of SIMD types and behaviours. Also, this construct requires the concept of a mask vector (in essence a SIMD bool), which should be a concept factored into the SIMD design... On a side note, I've seen murmurings of support for syntax like you illustrate a few times (interpreting D arrays as candidates for hardware SIMD usage). While that MIGHT be a nice optimisation in isolated cases, I have very serious concerns about standardising that as the language mechanic for dealing with SIMD data types. I wrote a couple of emails about that in the past though.