> On Thu, Aug 15, 2019 at 4:17 PM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > > On Tue, Aug 6, 2019 at 5:44 PM Martin Liska <mli...@suse.cz> wrote: > > > > > > > > > > > > gcc/ChangeLog: > > > > > > So I suppose this isn't to call operand_equal_p on two FIELD_DECLs > > > but to make two COMPONENT_REFs "more equal"? If so I then > > > > yes. The patch originates from my original patchset I believe and it is > > what ICF does. > > > I suggest to make this change "local" to the COMPONENT_REF handling. > > > This also interacts with path-based disambiguation so you want to make > > > sure to only make things equal here iff it wouldn't change the outcome > > > of path-based analysis. Honza? > > > > Indeed this can be handled as part of COMPONENT_REF match. > > Access path oracle here basically checks: > > 1) that MEM_REF type matches (we want predicate for this) > > 2) if it finds type match via same_type_for_tbaa and then it applies > > the assumption about disjointness or overlap > > > > So I guess ideally we should > > > > 1) do matching part of COMPONENT_REF > > 2) compare OFFSET, BIT_OFFSET > > This establishes that the access has same semantics. > > 3) for -fno-strict-aliasing be happy > > 4) for -fstrict-aliaisng check if access path applies (we should export > > predicate from tree-ssa-alias as discussed earlier) > > 5) compare types by same_type_for_tbaa_p > > Ick. This smells like a layering violation to me. IMHO this extended > equality handling should be handled with the overloading/callback > and not in native operand_equal_p. Either on the level of the > COMPONENT_REF itself (sounds like that would be needed) > or the FIELD_DECL. Not sure if the above suggestions make > it neccessary to look at more than a single COMPONENT_REF/FIELD_DECL > in the access path. If so then watch out for quadraticness as operand_equal_p > traverses a reference chain...
I suppose we want to match whole access paths at once, since only having the MEM_REF allows one to check whether access path oracle applies to the given reference or not... Honza > > Richard. > > > Honza