Re: g++ and aliasing bools

[Daniel Berlin <dan@dberlin.org>]

On 25 Jan 2002, Gabriel Dos Reis wrote:

> kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> 
> [...]
> 
> | I am very much against the idea of defining a change to be "correct" if
> | it doesn't cause any regression test failures.  You have to be able to make
> | an argument that a change is correct independently and the regression tests
> | serve as a debugger of (among other things) that proof.
> 
> I completely agree with Kenner and Mark.  Given, current ABIs
> supported by g++, aliasing detection is a very subtle issue and we
> should resist from the temptation of not proving that our algorithms
> are correct;
Aliasing is very hard to reason about formally, because no matter what you 
do, you start running into the undecidability issue.
In fact, in papers on static type determination for C++ (Do a search on 
researchindex.org), i've yet to see a *single* formal proof of any kind 
offered that they are correct.  They make statements about what language 
features they support, but never *why* or even prove that they support 
them.
It is simply assumed they are conservative enough.
If you think i'm going to write a formal proof that our aliasing for C 
structs, and thus, for the restricted case we are trying to make gcc 
handle for C++, you would be incorrect. I have neither the time, nor the 
inclination. It has nothing to do with whether i value correctness for 
speed, and everything to do with the fact that i'm not going to get myself 
into the kind of time I see something like that taking.
It's, IMHO, not something that as mark claims, is reasonably enough 
defined to do such a thing. If it was, others would have done it before.  
Mark's claim that if the underlying algorithm is easy, reasoning about it 
should be, is also not quite right.
Take Fermat's theorem, for instance.
So IMHO, that ends the discussion of trying to improve g++ TBAA 
for me.
I'm happy to let you guys require that someone formally reason about this 
stuff (I don't think it'll ever happen, but hey, i'm young and 
idealistic. Oh, wait...). It's just not gonna be me.

>  simply because correctness should come first, speed later.Of course.
> That doesn't mean I'm against any effort to improve alias analysis in
> g++, I'm simply against a change which doesn't consider correctness as
> serious issue.
What the heck is that supposed to mean?
Nobody has said correctness is not a serious issue.
I just don't think for simple cases, that it's a particularly *hard* 
issue.
Which is why we are talking about handling cases where what we have are 
effectively C  structs in C++ (IE nothing that inherits from anything 
else), which we handle properly for C already.
*Anything* is better than nothing, which is what we have now.
Formally proving things about simple C++ class aliasing, however, is not 
something i'm going to attempt.
So it'll have to wait for someone else.

Back to bugzilla work,
Dan