Nathan Sidwell <nathan@codesourcery.com> writes:
| Gabriel Dos Reis wrote:
| > Michael Veksler <VEKSLER@il.ibm.com> writes:
| > [...]
| > | The code is not very simple, and different codes will get optimized
| > | differently.
| > | The user will have to learn how to write this piece of code differently for
| > | each
| > | processor to have best results.
| > | | int wrap_sum(int a, int b)
| > | {
| > | if ( (a<0) != (b<0))
| > | return a+b; // Different sign, no overflow possible.
| > | unsigned sum = (unsigned) a + b;
| > | if (sum <= MAX_INT)
| > | return sum;
| > | sum -= MIN_INT;
| > | if (sum > MAX_INT) // can be eliminated for 2's complement
| > | abort(); // oops
| > | return (int)sum + MIN_INT;
| > | }
| > | | It does not look too good optimization-wise.
| > Thanks for providing this example. This is the sort of thing I
| > faced. With pipeline process, it does harm.
|
| Please explain why
| int wrap_sum (int a, int b)
| {
| return (int) ((unsigned)a + (unsigned)b));
| }
| is unacceptable
Notice that in your rendition you're assuming that you can convert any
unsigned value > INT_MAX to a int without invoking undefined behaviour.
Thus the question is whether you're accepting that as documented
behaviour of GCC, and if so, then I'm interested in which ways it
would differs from saying that is_modulo is true. That is useful for
improving over the current situation, may I point out.