On Wed, May 13, 2009 at 1:49 PM, Dag Sverre Seljebotn
<[email protected]> wrote:
> Yes, but these are only used in temporaries which are presumably read just
> after. Wouldn't the compiler be able to optimize it? E.g.
>
> short a = ..., b = ..., c;
> long long long long int temp;
>
> temp = a + b;
> c = temp;
>
> It seems plausible that the compiler could decide that temp could be made
> a short (?). But it definitely needs investigation to see exactly which
> sort of situations the knowledge about the size is used in.

This doesn't work in more complicated situations.

unsigned int a=..., b=..., c=..., d = ..., result;
unsigned long long temp1, temp2, temp3, temp4, temp5, temp6;

temp1 = a+1;
temp2 = b+1;
temp3 = c+1;
temp4 = d+1;
temp5 = temp1*temp2;
temp6 = temp3*temp4;
result = temp5/temp6;

And assume that int is 32 bits, long long is 64 bits.

Here C semantics guarantee that temp5 and temp6 are computed to full
64-bit resolution, and that the division is done in 64 bits (and then
truncated to 32 bits).  But if the temporaries were unsigned int,
instead, then temp5 and temp6 would be truncated to 32 bits before
doing the division.  So the C compiler can't possibly optimize temp5
and temp6 to unsigned int.  (I believe it could optimize temp1 ..
temp4 to unsigned int, as long as it still used 32x32->64 multiplies
to compute temp5 and temp6.)

I certainly have written C code that depends on the compiler exactly
following the C semantics for overflow on unsigned types.  I don't
remember if I've written such code in Cython (probably not).

Carl
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to