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: Do not compute alias sets for types that don't need them


> On Tue, 26 May 2015, Jan Hubicka wrote:
> 
> > > Hi,
> > > 
> > > On Fri, 22 May 2015, Jan Hubicka wrote:
> > > 
> > > > Index: tree-streamer-out.c
> > > > ===================================================================
> > > > --- tree-streamer-out.c	(revision 223508)
> > > > +++ tree-streamer-out.c	(working copy)
> > > > @@ -346,6 +346,7 @@ pack_ts_type_common_value_fields (struct
> > > >       alias-set zero to this type.  */
> > > >    bp_pack_var_len_int (bp, (TYPE_ALIAS_SET (expr) == 0
> > > >  			    || (!in_lto_p
> > > > +				&& type_with_alias_set_p (expr)
> > > >  				&& get_alias_set (expr) == 0)) ? 0 : -1);
> > > 
> > > I find such interfaces very ugly.  IOW, when it's always (or often) 
> > > necessary to call check_foo_p() before foo() can be called then the 
> > > checking should be part of foo() (and it should then return a conservative 
> > > value, i.e. alias set 0), and that requirement not be imposed on the 
> > > callers of foo().  I.e. why can't whatever checks you do in 
> > > type_with_alias_set_p be included in get_alias_set?
> > 
> > Because of sanity checking: I want to make alias sets of those types undefined
> > rather than having random values.  The point is that using the alias set in
> > alias oracle querry is wrong.
> 
> You could have just returned 0 for the alias-set for 
> !type_with_alias_set_p in get_alias_set.  That avoids polluting the
> alias data structures and is neither random or wrong.

Take the example of bug in ipa-ICF. It is digging out completely random types
from the IL and thinks it absolutely must compare alias sets of all of them
(the bug obviously is that it really should compare only those that matters).
It then throws random incomplete type to get_alias_set and obtain 0.  Which will
make it to silently give up if the "matching" random type is complete.

ICE here is a friendly reminder to the author of the optimization pass that he
is doing something fishy. It will also catch the cases where we throw memory access
of incomplete type to the function body by frontend/middleend bug instead of just
silently disabling optimization. I caught the Java interface glue issue with this.
(still need to fix that)

Now pack_ts_type_common_value_fields and RTL generation are differnt from the usual use of
alias set oracle in a sense that they do compute unnecesary alias sets by design.
They are not optimizations, they are IL stage transitions.

Honza


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