This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/9] operand_equal_p: add support for FIELD_DECL


> On Thu, Aug 15, 2019 at 4:17 PM Jan Hubicka <hubicka@ucw.cz> wrote:
> >
> > > On Tue, Aug 6, 2019 at 5:44 PM Martin Liska <mliska@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]