Re: signed int performance question

2017-02-28 Thread Liu Hao

On 2017/2/28 14:38, Eyal Itkin wrote:

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)
{
... 
}

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 am not sure but I believe that on some targets if (a + b) does 
overflow you get an interrupt/exception. So these two expressions aren't 
equivalent.



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".
What does 'in a purely theoretical manner' mean? In purely mathematical 
manner it may make sense, but in purely C programmatical manner it 
doesn't make any sense at all.



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.
The original code doesn't contain any UB given (c - b) does not 
underflow. You are no willing to transform code that doesn't contain UB 
into code that contains UB, are you?



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?

Just because we might be more efficient doesn't mean we should introduce UB.


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.
I am not sure what you want but there is an option `-Wstrict-overflow` 
that you may be interested in. Care must be taken that 
`-Wstrict-overflow=3` or above generates a lot of false warnings.


--
Best regards,
LH_Mouse



Re: signed int performance question

2017-02-28 Thread Andrew Haley
On 28/02/17 06:38, Eyal Itkin wrote:
> 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.

We can't change arithmetic which does not overflow into arithmetic
which might.  We re-order operations where we know that it's safe
to do so, but this one does not look safe to me.

Andrew.



gcc-5-20170228 is now available

2017-02-28 Thread gccadmin
Snapshot gcc-5-20170228 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 245794

You'll find:

 gcc-5-20170228.tar.bz2   Complete GCC

  MD5=9e38a49ef02ef37f753db5cca11b434e
  SHA1=1897735bec6d0c53f5411845b1bb9ec4d344d46c

Diffs from 5-20170221 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.