Re: [PATCH]: Fix PR tree-optimization/21407

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 2005-05-10 at 20:03 -0700, Mike Stump wrote:

> I'd tend to be conservative on both these issues and insist that gcc  
> do what it has done for more than a decade, survey what other  
> compilers do, discuss it in committee and then reach a decision,  
> document it, and then push it into the compiler.

I would agree, except most compilers I'm aware of gave up on type based
aliasing for C and C++ years ago, and only turn it on if you ask them
to.  

We could do the same in a year or two (IE without any real loss in our
ability to optimize) if we play our cards right, and that is what we
really want.

Of course, since I'm an optimization type person, I'd probably come up
with some very "strange" rules, given the chance.  
For example, I'd allow it when you pass a pointer to a structure, to get
back to a pointer to the containing structure, because i can see it
would be useful.
However, since I can't see it as in any way useful to do the same if you
pass a pointer to some POD datatype, i'd probably disallow it there (IE
if you pass &a.b, and b is an integer field, you can't get back to a
legally.  If you pass &a.b, and b is a structure, you can get back
legally to a).  At least, that's my inclination.

Of course, no committee would ever go for that, because it's not
"pretty" enough to allow it in one case and not in another, even though
you can come up with a very convincing rationale (again, except to
commitees :P): "It's not useful to users in any other case, and hurts
optimization". 

But since I don't make the rules, and in fact, am not on any of these
committees, I just want to know what the consensus is so that i can make
our optimizers work as best as they can :)