This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 2/9] operand_equal_p: add support for FIELD_DECL
On Thu, Aug 15, 2019 at 4:17 PM Jan Hubicka <email@example.com> wrote:
> > On Tue, Aug 6, 2019 at 5:44 PM Martin Liska <firstname.lastname@example.org> 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...