Question

In the CUDA C Best Practices Guide there is a small section about using signed and unsigned integers.

In the C language standard, unsigned integer overflow semantics are well defined, whereas signed integer overflow causes undefined results. Therefore, the compiler can optimize more aggressively with signed arithmetic than it can with unsigned arithmetic. This is of particular note with loop counters: since it is common for loop counters to have values that are always positive, it may be tempting to declare the counters as unsigned. For slightly better performance, however, they should instead be declared as signed.

For example, consider the following code:

    for (i = 0; i < n; i++) {  
         out[i] = in[offset + stride*i];  
    }

Here, the sub-expression stride*i could overflow a 32-bit integer, so if i is declared as unsigned, the overflow semantics prevent the compiler from using some optimizations that might otherwise have applied, such as strength reduction. If instead i is declared as signed, where the overflow semantics are undefined, the compiler has more leeway to use these optimizations.

The first two sentences in particular confuse me. If the semantics of unsigned values are well defined and signed values can produce undefined results, how is it the compiler can produce better code for the latter?

Answer 1

The text shows this example:

for (i = 0; i < n; i++) {  
     out[i] = in[offset + stride*i];  
}

It also mentions “strength reduction”. The compiler is allowed to replace this with the following “pseudo-optimised-C” code:

tmp = offset;
for (i = 0; i < n; i++) {  
     out[i] = in[tmp];
     tmp += stride;
}

Now, imagine a processor that only supports floating point numbers (and integers as a subset). tmp would be of type “very large number”.

Now, the C standard says that computations involving unsigned operands can never overflow, but instead are reduced modulo the largest value + 1. That means that in the case of unsigned i the compiler has to do this:

tmp = offset;
for (i = 0; i < n; i++) {  
     out[i] = in[tmp];
     tmp += stride;
     if (tmp > UINT_MAX)
     {
         tmp -= UINT_MAX + 1;
     }
}

But in the case of signed integer the compiler can do whatever it wants. It doesn’t need to check for overflow – if it does overflow then it’s the developer’s problem (it could cause an exception, or produce erroneous values). So the code can be faster.