Would SIMD consider signed overflow undefined?

[Myriachan]

Would the SIMD proposals consider signed integer overflow to be undefined?

SIMD programming uses a lot of tricks for performance, including things like reinterpreting values as the "wrong" type, and abusing two's-complement overflow mechanics.  This is often done irrespective of whether the result is ultimately considered signed or unsigned.

Melissa

[Mathias Gaunard]

On 19 March 2018 at 21:04, Myriachan <myri...@gmail.com> wrote:

Would the SIMD proposals consider signed integer overflow to be undefined?

SIMD programming uses a lot of tricks for performance, including things like reinterpreting values as the "wrong" type, and abusing two's-complement overflow mechanics.  This is often done irrespective of whether the result is ultimately considered signed or unsigned.

The standard library should expose any functionality that any trick can stay in the implementation without the user having to worry about it.

One example of a "trick" is that the value for true is usually the same as -1. So you can implement `a.where(condition)++' as `a - condition'.

 

[Thiago Macieira]

SSE2 through AVX2 lacks unsigned comparison ability, so the usual trick is
also to subtract INT_MIN from both sides and perform a signed comparison. This
is a clear underflow situation.

An implementation could hide that fact when abstracting the SIMD details, but
that's another story. Libraries like Eigen aren't low-level SIMD manipulation,
but more like implementing certain useful algorithms. I don't think you can
abstract low-level SIMD and still get the most performance (which is the point
of SIMD).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center