Gabriel Dos Reis wrote:
Michael Veksler <[EMAIL PROTECTED]> 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 (provided we're on the standard 2's complement machine where the
mapping between negative ints and unsigned is *implementation defined* to be the
sane mapping, which I might point out you've already assumed in the wrap_sum I
quoted).
nathan
and whoever silently removed gcc@gcc.gnu.org, shame on you
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED] :: http://www.planetfall.pwp.blueyonder.co.uk
