This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC optimizes integer overflow: bug or feature?
- From: Robert Dewar <dewar at adacore dot com>
- To: Dave Korn <dave dot korn at artimi dot com>
- Cc: 'Denis Vlasenko' <vda dot linux at googlemail dot com>, 'Paul Brook' <paul at codesourcery dot com>, gcc at gcc dot gnu dot org, 'Andrew Haley' <aph at redhat dot com>, 'Paolo Bonzini' <bonzini at gnu dot org>, bug-gnulib at gnu dot org
- Date: Fri, 22 Dec 2006 12:28:50 -0500
- Subject: Re: GCC optimizes integer overflow: bug or feature?
- References: <005101c725eb$bce0a650$a501a8c0@CAM.ARTIMI.COM>
Dave Korn wrote:
On 22 December 2006 00:59, Denis Vlasenko wrote:
Or this, absolutely typical C code. i386 arch can compare
16 bits at a time here (luckily, no alighment worries on this arch):
Whaddaya mean, no alignment worries? Misaligned accesses *kill* your
performance!
is it really worse to do one unaligned 16-bit read, than two separate
8-bit reads? I am surprised ... and of course you have the gain from
shorter code, reducing i-cache pressure.
I know this doesn't affect correctness, but the coder might well have known
that the pointer is unaligned and written two separate byte-sized accesses on
purpose; volatile isn't the answer because it's too extreme, there's nothing
wrong with caching these values in registers and they don't spontaneously
change on us.