This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

signed int performance question


Hello,

I wanted to ask a question regarding the compilation of code samples
like the following:
"
int a = fetch_value();
int b = fetch_value();
int c = SOME_BIG_CONSTANT;

if ( c - b < a)
{
    ... <error case>
}

pass_value(a + b);
return a + b;
"
The value "a + b" is used 3 times in this snippet, while the first use
is hidden in the if check. It seems that changing the if check to "if
( c < a + b ) " will allow the compiler to generate a more efficient
assembly code: 1 addition, used 3 times. However in all of my checks,
all GCC versions will prefer to calculate both the subtraction and the
addition, and to only use the addition's result 2 times.

I know that the case with unsigned integers is that all operations are
done in a modulu 2 ^ 32, and so changing the condition will change the
logical meaning of the check.
However, in signed integers, the logical meaning of any relation check
is only the theoretical meaning of the order relation between the
numbers in the group Z. Meaning that in a purely theoretical manner "a
+ b < c" is a relation order that is equivalent to "a < c - b" or even
" 0 < c - b - a". The only exception here is about any possible
integer overflow (above MAX_INT) or underflow (below MIN_INT), however
such cases are specified to be undefined in the C standard, and should
not harm the possible efficiency of the code generation.

Since a C programmer that follows the standard, and writes such a code
check, means only to check relations between 3 signed numbers in the
group Z, is there a reason why not to update the if check and to
generate a more efficient code? In addition, is there a way to
optionally raise warning in similar cases, so to warn against possible
signed integer overflows, in case the programmer is not aware of the
dangers in his code.

Thanks for your time,
Eyal.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]