g++ and aliasing bools

[mike stump]

> Date: Fri, 25 Jan 2002 11:34:48 -0500 (EST)
> From: Daniel Berlin <dan@dberlin.org>
> To: Robert Dewar <dewar@gnat.com>
> cc: gcc@gcc.gnu.org, <kenner@vlsi1.ultra.nyu.edu>

> > And we need to prove that they are indeed
> > conservative estimates. We need to be able to prove that elements of
> > separate sets are indeed never aliased. 
> Herein lies the point you've ignored.  Using only the C++ language 
> standard, we can't do that, and it's quite possible we may place 
> things into separate sets that do in fact alias, because of the 
> implementation specific details.

To get concrete here, and because I didn't like how Dan worded this,
an example of such an issue is the reuse of stack slots for values
which have different alias sets.  Reusing stack slots is beyond the
standard (at least for C and C++), but reuse is mandated by users
expectation (to some degree).

However, this implementation choice does force us to think about
complex alias issues:

  { int i; i = 1; ... }
  { double d; d = 24; ... }

If one reuses the space for i for d, then one has to be careful to not
allow the write of i to be moved past any playing with d.  They
conflict (alias), even though through the rules of ANSI C, you will
not find a statement that they conflict.

I think this is the canonical example of what he is talking about,
Daniel, can you confirm this?

Also, think about inlining two routines into a single function:

  void foo1() { int i; i =1; ... }
  void foo2() { double d; d = 24; ... }

  void bar() { foo1(); foo2(); }

If we reuse the stack space for one, for the other one...

In the end, we have to ensure that the implementation is aliasing
correct.  If it is, then the only additional rules we need, are those
based upon mandates by the language.  Or put another, given an
aliasing correct backend, we need only consider rules from the
language spec.

There can be existing code in the backend, that is aliasing correct
for the existing ways in which we use it, but for which it is not
aliasing correct for more advanced uses.  This means, if we change how
think about aliasing in the frontend, we can introduce aliasing bugs.
An example of this would be reusing stack slots, and having a frontend
always use set 0.  The backend would be alias correct for how the
frontend used it.  And it would seem natural to put in more smarts
about aliasing into the frontend, but this would cause the stack reuse
to then be aliasing incorrect.