On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Uh, except as we've discovered, the RTL uses alias set 0, so whatever
> alias set you choose for these doesn't matter anyway to the RTL level.
Only in some cases. That was a kludge put in to fix some obscure bug and
left there. I hope we can remove it at some point, and think we can.
> No i mean the idea of making it a different alias set than the parent,
> but a subset of the parent.
Because it *is* the parent in most places, so it should be in all.
Again, the tree level relies on the documented (in the comments of
alias.c) fact that given a structure, the fields contained in a
structure will have alias sets that are strict subsets of the parent.
The bug reports are about cases where we have a struct foo * (where
struct foo contains int a:31), and foo pointer->a is claimed to not
alias with foo.a.
This is because we use the subset relationship to prune the set of
aliases that a pointer to the structure could touch (this is the only
case we get wrong, as the bug reports will show). We do not test
subset or equal, only strict subset. Since parent-alias set is not a
strict subset of parent-alias set, we determine they cannot alias.
I would much rather maintain the strict subset invariant than the
component_uses_parent_alias_set stuff, since this is the documented
invariant, and makes sense.
Adam's suggestion to use a new alias set that is
1. A subset of the parent structure's alias set.
*AND*
2. Not the same as the "type" (IE int in the case of int:31) of the field
Will not cause missed optimization. It will maintain the strict
subset relationship. It requires no component_uses_parent_alias_set
function.
His first patch, which simply makes #1 true, would cause missed optimization.
