------- Comment #105 from rguenth at gcc dot gnu dot org 2007-05-22 10:50
-------
Let me again do a step back and look at the problem from another view ;)
--
C++ aliasing imposes additional restrictions on transformations we
are allowed to do to memory references compared to C type-based
aliasing rules.
Consider two memory references A and B which we need to know whether
we can exchange them.
- If we can prove that both memory references are
to non-overlapping memory regions we always can exchange them (PTA
can provide this knowledge).
- We can always re-order two loads.
TBAA gives us another source of information to disambiguate the
two references. So, if TBAA says the two references do not conflict then
- we can hoist loads across stores.
*double = 1.0;
x = *int;
if *int aliases *double the program is invalid.
- we can sink stores across loads. (this is just the opposite view
of the above)
- we _cannot_ re-order stores.
- we _cannot_ sink loads across stores.
x = *int;
*double = 1.0;
the store to double may change the dynamic type of what *int
points to.
- we _cannot_ hoist stores across loads. (opposite view of the above)
Note that all the interesting stuff (hoisting loads and sinking stores)
is not affected by the stricter C++ aliasing rules.
The caveat is, that these rules do not map to our representation of
aliasing (VOPs) nor to type-based queries of the alias oracle.
--
So the proposal is to impose these additional restrictions ontop of
our alias representation and fixup passes that do not honour them.
One of them is loop load/store motion which messes up store ordering,
another is scheduling.
If anyone can come up with a clever way to encode the extra restrictions
into our IL be my guest (I wrapped my brain around this for some days now,
and only a may_reorder_accesses (A, B) style oracle can handle this, but
not VOPs in SSA form or something similar - we'd need a DU chain
and another set of VOPs but that looks way too costly)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
