This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Aliasing fun
- From: Joe Buck <jbuck at synopsys dot COM>
- To: dan at dberlin dot org (Daniel Berlin)
- Cc: dewar at gnat dot com, gcc at gcc dot gnu dot org
- Date: Fri, 25 Jan 2002 08:55:52 -0800 (PST)
- Subject: Re: Aliasing fun
> My point about undecidability is that using just the C++ standard, it's
> not just that we can be conservative and get it correct, it's quite
> possible we'll get the wrong answers for type alias sets, because of
> implementation specific details that the C++ standard doesn't define.
Sigh. There's undecidability only if you insist on getting the exact
solution, but an exact solution isn't necessary. All undecidability
means to a compiler writer is that analysis questions yield a three-way
result: yes, no, and maybe. You do what you can to decrease the size
of the maybe set, and then you handle it conservatively. But you knew that.
> Mark wants a semi-formal proof that the ABI details provide us enough to
> get it right all the time, before we try to do it for all cases.
I think that you are misreading Mark's request. Given two memory
accesses, if we ask the question "can they alias" and GCC provides the
wrong answer, there are two possibilities:
False positive: gcc will still generate the correct code, but it may be
slower (re-reading something from memory that is already in a register)
False negative: gcc is likely to generate bad code.
So all you need to prove is that you don't get false negatives. It would
also be nice to show why you get fewer false positives than we currently
get.