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: Enable pointer TBAA for LTO


> > Now alias set of the initialization is alias set of "struct a". The alias set
> > of of the pointer store is "float *".  We ask alias oracle if "struct a" can
> > conflict with "float *" and answer is no, because "int *" (component of struct
> > b) and "float *" are not conflicting.  With the change we record component
> > alias as follows:
> 
> Ah, with my original pointer globbing I side-stepped this.  So are
> you _really_ sure that we want to handle int * different from float *?
> Because that makes the situation much more complicated in these cases.

Yep, keeping track of different pointer types in C++ is really important
and moreover the old globbing was not able to deal with C/Fortran compatibility
fun anyway.

Average higher level C++ code has dozen of differently typed containers for
random stuff and shuffles the pointers around them in memory.  Without being
able to track down pointers stored in memory  there is no hope to optimize the
code.

This very basic pointer LTO reduced rodata cc1 binary by 7% which I think are
from 99% the removed sanity checking __FUNCTION__ locators. 

Globing all pointers to void * is just part of the problem anyway. The previous
code did not implemented Fortran/C interoperability correctly anyway.  I hope
that with these changes we have infrastructure robust and flexible enough
to model more precisely what we really want.

> > Here the situation is reverse to the case above : because array type is
> > inherited from element type, we can't have TYPE_CANONICAL more globbed for
> > array than we have get_alias_set.  In this case the problem appeared when
> > TYPE_NONALIASED_COMPONENT array previaled in type merging other arrays.  The
> > situation got worse with pointer, becuase array of pointers of one type could
> > prevail array of pointers of other type and then the array type gets different
> > alias sets in different units.  This seems to work for C programs, but is
> > wrong.  I will send patch and separate explanation after re-testing final
> > version shortly.
> 
> I feel we need to document all this somewhere.

Yeah, that would be a good idea.  Probably comment at beggining of alias.c?
I was thinking of moving the code to one place, perhaps moving 
gimple_canonical_type from tree.c to alias.c would make sense, or inventing
new place for this.

Moreover I was thinking of extending type verifier to check that all components
of a type alias with the whole tihng, so we do not run into bugs like this again.
Together with the TBAA checking in lto-symtab.c it should make it pretty
hard to make nasty bugs like this.

Thanks,
Honza
> 
> Richard.
>  
> > Honza
> > 
> > 
> 
> -- 
> Richard Biener <rguenther@suse.de>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)


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