> >> > >> Well, in tree-ssa code we do assume these to be either disjoint objects > >> or equal (in decl_refs_may_alias_p that continues in case > >> compare_base_decls is -1). I am not sure if we win much by threating > >> them differently on RTL level. I would preffer staying consistent here. > > Yeah, I see your point. My concern here was that the fallback case > applies to SYMBOL_REFs without decls, which might not have been visible > at the tree-ssa level. E.g. they might be ABI-defined symbols that have > no known relation to source-level constructs. > > E.g. the small-data base symbol _gp on MIPS points at a fixed offset > from the start of the small-data area (0x7ff0 IIRC). If the target > generated rtl code that used _gp directly, we could wrongly assume > that _gp+X can't alias BASE+Y when X != Y, even though the real test > for small-data BASEs would be whether X + 0x7ff0 != Y. > > I don't think that could occur in tree-ssa. No valid C code would > be able to refer directly to _gp in this way. > > On the other hand, I don't have a specific example of where this does > go wrong, it's just a feeling that it might. I can drop it if you > think that's better.
I would lean towards not disabling optimization when we have no good reason for that - we already did it bit too many times in aliasing code and it is hard to figure out what optimizations are missed purposefully and what are missed just as omission. We already comitted to a very conservative assumption that every external symbol can be alias of another. I think we should have originally required units that reffers to same memory location via different symbols to declare it explicitly (i.e. make external alias to external symbol), but we do not even allow external aliases (symtab supports that though) and also it may depend on use of the module what symbols are aliased. We also decided to disable TBAA for direct accesses to decls to allow type punning using unions. This keeps the offset+range check to be only means of disambiguation. While for modern programs global arrays are not common, for Fortran stuff they are, so I would preffer to not cripple them even more. (I am not sure how often the arrays are external though) Perhaps we could simply test if symbol has associated decl and be conservative for symbols w/o decl. It is however just my preference. I can live with being conservative everywhere. Honza > > > So that's because if an alias (via alias attribute) is not visible > > then it can be assumed to not exist. Which means the bug is that > > with section anchors we do not know which variables can be refered > > to via the specific anchor? > > No, we do know that. > > > (if there's something like a "specific" > > anchor) That looks like the actual defect to me? I see we have > > block_symbol and object_block which may have all the data needed > > in case accesses are somehow well-constrained? > > Right. And the patch does take advantage of that information. > E.g. the existing: > > if (SYMBOL_REF_BLOCK (x_base) != SYMBOL_REF_BLOCK (y_base)) > return 0; > > says that symbols can't alias if they're known to belong to different > blocks. And if symbols are in the same block, the behaviour of the > patch is to adjust the relative offsets to account for the positions > of the symbols in the block. > > The problem is just that “unequal offsets imply no alias” doesn't > hold for section anchors. The offset of the symbol from an anchor > has to be taken into account. If we have: > > (symbol_ref X) > (plus (symbol_ref ANCHOR) Y) == unpreempted X > > then ignoring Y gives two false results, a false positive and a false > negative: > > (a) the existing code might wrongly assume that an access to X+0 could > alias an access to ANCHOR+0, because the offsets are equal. > > (b) the existing code would wrongly assume that an access to X+0 can't > alias an access to ANCHOR+Y, because the offsets are unequal. > > The relative offset has to be adjusted by Y first, before applying > the “unequal offsets imply no alias” rule. > > >> Otheriwse the patch looks good to me. > > > > So let's go with it? It looks like for decl vs. section anchor we > > can identify the offset of the decl in the anchor block and thus > > determine a offset adjustment necessary to perform an offset based > > check, no? > > Yeah, that's what the patch is trying to do. > > Thanks, > Richard
