Jan Hubicka <hubi...@ucw.cz> writes: >> On Mon, 18 Jan 2021, Richard Sandiford wrote: >> >> > Jan Hubicka <hubi...@ucw.cz> writes: >> > >> >> >> > >> >> 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) >> > >> > OK, the version below drops the new -2 return value and tries to >> > clarify the comments in compare_base_symbol_refs. >> > >> > Lightly tested on aarch64-linux-gnu so far. Does it look OK if >> > full tests pass? >> >> OK from my side. > > OK too, thanks! > Honza
Thanks, pushed to master after testing on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu. I don't think it's suitable for backports. Richard
