On 9/10/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> What is an example program in that meets the requirements I gave above
> >> -- i.e., allows the compiler to prove that two same-typed pointers do
> >> not alias (whether by the compiler's cleverness, use of "restrict", or
> >> whatever), but where the compiler must still assume that the values of
> >> the pointers might be the same?
> >
> > I see I misinterpreted your sentence. I don't think a testcase that
> > holds all your requirements can be constructed as they
> > contradict each other. Can you give one?
>
> No -- I don't think any such test case should exist. But, IIUC, one of
> your proposals could lead to the existence of such a test case. In
> particular, I understood you to be suggesting that we might be able to
> make the "malloc" attribute work for any implementation of "operator
> new" by saying that while the compiler could assume that "*p" and "*q"
> did not alias, the compiler was none-the-less not allowed to assume that
> "p != q".
>
> My point was that this seems like a very strange requirement to impose
> on the compiler, and that the compiler -- now, or in future -- is very
> likely to make exactly that deduction, since it is logically true. More
> broadly, my point was that a universe in which "*p does not alias *q"
> fails to imply "p != q", for "p" and "q" pointers of the same type, is a
> weird place to be.
Well, we have that now:
int *q = new int;
delete q;
int *p = new int;
delete p;
if (q != p)
cout << "different";
we cannot optimize the test to be always true. The point is that alias
analysis tells us something about accesses to *q and *p, but neither
on lifetime of *q and *p nor lifetime of q and p (and thus their value).
The only value analysis valid on pointers is non-NULLness which we
can derive from accesses to the pointed-to memory location (ok, assuming
the OS really traps on accesses to address zero, which is not true in
general).
I don't think my proposal opens up more "problems" in this area.
Richard.
