RE: [GD-General] The joy of type aliasing and C

[Neil S. <ne...@r0...>]

> The problem with int x=*(int *)&f; is sort of side effect here.
> I don't really know for sure why there must be a problem, 
> because the aliasing of the values is sort of obvious, and 
> could be deduced separately.  Maybe the comittee just wanted 
> to keep the definitions simple?

The aliasing in that example is fairly obvious, but it can easily become
non-obvious, which is why compilers give you the option to switch "assume no
aliasing" off.

Optimisation with optimal handling of aliasing is a virtually unsolvable
problem in C/C++, as they give you more than enough rope to hang yourself
several times over. The committees have tried to go down the "tightening up"
route, where they make it illegal to do certain things that will break the
optimiser but this has, on the whole, failed, mainly because the compilers
can't stop you doing it.

The "restrict" keyword was another attempt to solve the problem, by letting
programmers tell the compiler which pointers it is safe to assume no
aliasing on. The advantage of this approach is that the optimiser will not
make any mistakes, the downside being that the compiler will not be able to
perform certain optimisations without it, so you have to put it almost
everywhere if you want full optimisation. You could argue that you only need
full optimisation in a few places, so the use of restrict could be kept
quite small in practice.

An alternative would be to have an "alias" keyword, which is used to tell
the compiler what *not* to perform these optimisations on. The obvious
advantage is that it will optimise a lot more stuff, but the penalty is that
if you forget to use it where it's needed, your code will break.

- Neil.