------- 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