Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: 64 bit divide/mod in 2.4.0-test5 | Date | 4 Aug 2000 17:51:17 -0700 |
| |
In article <8mflv4$lit$1@cesium.transmeta.com>, H. Peter Anvin <hpa@zytor.com> wrote: > >There is also big difference on some architectures between 64/32 = 64 >and 64/32 = 32 (the latter is a single, albeit slow, instruction on >x86.) I'm rather surprised gcc doesn't handle this -- it seems as an >obvious optimization. > >Could we get the gcc people to look at this?
Probably not.
Doing 64/32->32 thing as a single instruction on x86 is an illegal optimization: if your source code looks like
unsigned long a, b; unsigned long long c;
a = c / b;
then according to the C language the c/b division is actually a 64/promoted64 bit division, and then the 64-bit result casted down to 32 bits.
What's the difference? Overflow. The cast from 64 bits to 32 bits cannot overflow, so gcc would have to basically always do the 64/32->64 bit division, and then just silently drop the extra bits in order to get the right end result.
Now, that 64/32->64 bit division is fairly simple on x86 (certainly simpler than the 64/64->64 one), and that's actually what do_div() will use on x86. But it's two "div" instructions, not one (the first one can often be optimized away if the upper 32 bits are usually 0, which is the case 99%+ of the time with most regular distributions of numbers).
Note that the 64/32->64 division is a _lot_ simpler than the 64/64->64 one, so this is definitely still worth doing. But it's not a single instruction.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |