Richard G. Riley wrote:
"Me"posted the following on 2006-03-11: disallowed is because of aliasing. Here is a simple example (assume int
and long have the same size/representation on this implementation):
Is there a difference with, e.g.,
foo(*(long*)&intv,10);
intv =5;
or may the compiler still make the same assumptions?
I have no clue what that example means but I think what you're asking
is for the compiler to rely on static analysis. This has a few
problems, the major issue being code that crosses 2 translation units.
In this case, the static analysis is delayed until link time. For
static linking, this can be done but with dynamic linking this is very
difficult or impossible depending on the platform.
There are a few cases, lets call S static analysis and A type-based
alias analysis
- This is a very crappy compiler. Most compilers in debug mode do
this.
S - Ignore the type system. The types are just used for the type system
and to set size/alignment/representation. You're basically running an
optimizing BCPL compiler with friendlier syntax on non-word
aligned/sized objects at this point. Your average C programmer assumes
this is correct.
A- Don't do any object tracking at all. I don't know of any compilers
that do this. It basically assumes the programmers know what they're
doing and if they lie, their program is likely to crash (if you're
lucky). This is what the C standard assumes is correct.
SA- This is what most compilers do with full optimizations. Depending
on the compiler, this is what happens:
if it detects you lying:
- it can warn you. This is good for tools like lint that detect broken
code.
- it can side with the aliasing and assume the programmer knows what
they're doing (case A). This leads to the fastest code at the expense
of crashing.
- it can side with the object tracking that assumes the programmer is
an idiot (case S). The code is slower than siding with the aliasing
case but it works.
if it detects no lie:
- rely on both type and object information to generate the fastest code
possible.
if it can't decide if you lied or not:
- make a conservative choice to allow for bad programmers (case S)
- make an aggressive choice to allow for faster code (case A)
What you're suggesting is for the compiler to do SA but be
conservative. It's a bad idea to rely on this because you're just
wallpapering over the problem and as your code piles up over time, this
bug becomes way more expensive/difficult to detect and fix. The sad
reality is that the majority of code you find makes this kind of
mistake because they're ignorant of what the standard says and
compilers in the past weren't aggressive with optimization based on the
type system.