Re: type based aliasing again

["Kaveh R. Ghazi" <ghazi AT caip.rutgers.edu>]

 > From: David Edelsohn <dje@watson.ibm.com>
 >  
 >         When the compiler and architecture allow this construct to
 > produce reasonable results and other compilers produce reasonable
 > results and GCC still can produce reasonable results more often when
 > an optional optmization is not applied, then why not allow tihs
 > construct to work unless the user specifically request more aggressive
 > optimization?
 > David

	I have concerns about removing strict aliasing from -O2.

Most users probably use -O2 simply because that's what most people
have learned do, e.g. because autoconf defaults to when -O2 you build
a package.  So I think that strict aliasing will get much less usage
even when it is safe to use it.

Thus two things happen:

1.  The code GCC generates by default performs more poorly.

This has already been discussed.  It may or may not be a big deal
today.  But future opts may hinge on aliasing.

2.  Strict alising gets less real world testing.

IMHO the second concern is a big one.  If an optimization gets less
testing, it is usually more buggy, meaning even less people will use
it.  It is a vicious circle.

E.g. I think the large number of problems we've seen with inlining and
loop unrolling are due in part to the fact that they are not in -O2.
There are reasonable arguments as to why they are not there, (like
they may not make the code faster or may bloat your code) but these
particular arguments don't apply to strict aliasing.

	I haven't decided yet whether the testing issue is enough to
reject doing this, but I thought it should be part of the discussion.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions