This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]